đź“… Original date posted:2022-02-01
đź“ť Original message:
> Specific items, maybe not, but maybe a use case for keeping description
> hash for this.
>
> You can't keep hash without making it possible to use it for AOPP-style
verification. The exchanges would just ask users to make invoices with that
hash.
> the envisioned scenario is that this AOPP-style regulation gets
> restrictive enough that nobody can use regulated custodians to make
> payments.
>
Not necessarily, it could also be just so frequent people develop muscle
memory and avoid even trying to pay from exchanges.
> Why do we need to comply with extreme node level KYC enforcement to make
> this the case?
>
I don't know if we *need* it maybe better education can replace it but
surely it helps.
> The enforcement won’t stop with the scenario you’ve described if everyone
> is complying and supporting these regulations in the first place.
>
In a way it was too late when KYC came to exist. Note that slippery slope
can be fallacious argument and I think it's the case here. The specific
regulation is only about proving that you aren't paying someone else. The
intention is for exchanges to not have to register as banks. The objective
is NOT to track people.
> They will get worse. They are already talking about how to DOX the sender
> of a payment by signing a message in a TLV field.
>
The only serious discussion I remember seeing about this proposed to make
it unlinkable. The recipient would not know which node it was.
> Also node IDs could be rotated.
>
> How so? Close down all channels, shut down node, coinjoining utxo’s and
> spin up a new one?
>
No, it literally only requires changing the receiver implementation to
accept messages for any known node ID. The only problem is channel id being
static and we need some protocol for private channels to generate new IDs.
> "KYC" of a private node ID is completely meaningless
>
> This will be the realization of the regulators as well.
>
When they get people smart enough to understand it they will also
understand the only solutions are ban Bitcoin completely or give up. We
can't change it anyway.
> This also assumes there are protective mechanisms in place to make sure a
> “private node” is actually private because that’s not the case and there
> are enough gotchas to break down that assumption.
>
That's also what I said. I encourage you to work on these instead of
removing description.
> An operator of popular public node can just connect to self and pretend
> it's some random person routing through him. It's essentially impossible to
> prove it's not the case.
>
> I think this is a good thing to do but if not done correctly, there can be
> enough correlations to break this down.
>
The only way I can see it being done incorrectly is user entering invoice
from the public node where he shouldn't. Can you see any other?
> Ideally, it’s like you’ve said, “popular public node”. What about everyone
> else?
>
Even unpopular public nodes have plausible deniability even though they
might have harder time. Fixing private nodes should be among top priorities.
> There is not a hard & fast rule that no custodian is processing anything
> except to the user’s (assumingly) private nodes.
>
> Not a big deal except for uninformed dissidents. People who break unjust
dictatorship laws should be more careful. This can't be changed anyway.
> Nodes are being KYC’d now. Invoices and payment reasons are being
> aggregated in mass. How do we stop this now except by removing the ability
> for it *to* happen?
>
We don't need to stop it, making it meaningless is a possibility. And
certainly stopping it by screwing up something else is not a good strategy.
Regardless, we need to educate people about this simple rule:
NEVER put invoices from others into any KYC wallet.
Finally, fixing privacy issues like ID reuse is much more important and
productive than removing description.
Cheers
Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220201/ff49815b/attachment.html>;
Martin Habovštiak [ARCHIVE] /
npub186…y2s83
2023-06-09 15:05:06
in reply to nevent1q…6ut4
Author Public Key
npub186h7xm74e8dqvz64kzhx8aq3j47lwf3emlxl7w8j0d0thrth65vs9y2s83Seen on
wss://relay.noswhere.comPublished at
2023-06-09 15:05:06Event JSON
{
"id": "20288153ab77764c909121cc75224ca787574b91ad95ade495fb9f4376c1e904",
"pubkey": "3eafe36fd5c9da060b55b0ae63f411957df72639dfcdff38f27b5ebb8d77d519",
"created_at": 1686315906,
"kind": 1,
"tags": [
[
"e",
"805aac32ee8ccf8a24c85af961457e821573e6fb4f7000802f5f5edc216ae2cd",
"",
"root"
],
[
"e",
"fc41fcb44e3449c7a81cfd20a167406be78e205a8a2b710a280ecdc9318bcf91",
"",
"reply"
],
[
"p",
"a5d6d8a256af27eabf38d4a0012b7d9adaa969fa06418df529e530682189b816"
]
],
"content": "📅 Original date posted:2022-02-01\n📝 Original message:\n\u003e Specific items, maybe not, but maybe a use case for keeping description\n\u003e hash for this.\n\u003e\n\u003e You can't keep hash without making it possible to use it for AOPP-style\nverification. The exchanges would just ask users to make invoices with that\nhash.\n\n\u003e the envisioned scenario is that this AOPP-style regulation gets\n\u003e restrictive enough that nobody can use regulated custodians to make\n\u003e payments.\n\u003e\nNot necessarily, it could also be just so frequent people develop muscle\nmemory and avoid even trying to pay from exchanges.\n\n\u003e Why do we need to comply with extreme node level KYC enforcement to make\n\u003e this the case?\n\u003e\nI don't know if we *need* it maybe better education can replace it but\nsurely it helps.\n\n\u003e The enforcement won’t stop with the scenario you’ve described if everyone\n\u003e is complying and supporting these regulations in the first place.\n\u003e\nIn a way it was too late when KYC came to exist. Note that slippery slope\ncan be fallacious argument and I think it's the case here. The specific\nregulation is only about proving that you aren't paying someone else. The\nintention is for exchanges to not have to register as banks. The objective\nis NOT to track people.\n\n\u003e They will get worse. They are already talking about how to DOX the sender\n\u003e of a payment by signing a message in a TLV field.\n\u003e\nThe only serious discussion I remember seeing about this proposed to make\nit unlinkable. The recipient would not know which node it was.\n\n\u003e Also node IDs could be rotated.\n\u003e\n\u003e How so? Close down all channels, shut down node, coinjoining utxo’s and\n\u003e spin up a new one?\n\u003e\n\nNo, it literally only requires changing the receiver implementation to\naccept messages for any known node ID. The only problem is channel id being\nstatic and we need some protocol for private channels to generate new IDs.\n\n\u003e \"KYC\" of a private node ID is completely meaningless\n\u003e\n\u003e This will be the realization of the regulators as well.\n\u003e\nWhen they get people smart enough to understand it they will also\nunderstand the only solutions are ban Bitcoin completely or give up. We\ncan't change it anyway.\n\n\u003e This also assumes there are protective mechanisms in place to make sure a\n\u003e “private node” is actually private because that’s not the case and there\n\u003e are enough gotchas to break down that assumption.\n\u003e\nThat's also what I said. I encourage you to work on these instead of\nremoving description.\n\n\u003e An operator of popular public node can just connect to self and pretend\n\u003e it's some random person routing through him. It's essentially impossible to\n\u003e prove it's not the case.\n\u003e\n\u003e I think this is a good thing to do but if not done correctly, there can be\n\u003e enough correlations to break this down.\n\u003e\nThe only way I can see it being done incorrectly is user entering invoice\nfrom the public node where he shouldn't. Can you see any other?\n\n\u003e Ideally, it’s like you’ve said, “popular public node”. What about everyone\n\u003e else?\n\u003e\nEven unpopular public nodes have plausible deniability even though they\nmight have harder time. Fixing private nodes should be among top priorities.\n\n\u003e There is not a hard \u0026 fast rule that no custodian is processing anything\n\u003e except to the user’s (assumingly) private nodes.\n\u003e\n\u003e Not a big deal except for uninformed dissidents. People who break unjust\ndictatorship laws should be more careful. This can't be changed anyway.\n\n\u003e Nodes are being KYC’d now. Invoices and payment reasons are being\n\u003e aggregated in mass. How do we stop this now except by removing the ability\n\u003e for it *to* happen?\n\u003e\nWe don't need to stop it, making it meaningless is a possibility. And\ncertainly stopping it by screwing up something else is not a good strategy.\nRegardless, we need to educate people about this simple rule:\n\nNEVER put invoices from others into any KYC wallet.\n\nFinally, fixing privacy issues like ID reuse is much more important and\nproductive than removing description.\n\nCheers\nMartin\n\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220201/ff49815b/attachment.html\u003e",
"sig": "d73e9e9f9f5412eed485d19d78389fb639d9a153d725608c14245f5a1b371679b5279092ead3474a30b125fbc0c1f2e09dd14405f12adcfd877a982d74a92f67"
}