From martin.habovstiak at gmail.com Tue Feb 1 18:10:45 2022 From: martin.habovstiak at gmail.com (=?UTF-8?Q?Martin_Habov=C5=A1tiak?=) Date: Tue, 1 Feb 2022 19:10:45 +0100 Subject: [Lightning-dev] Remove Description From Bolt11 Invoices In-Reply-To: <555D18B0-4104-4A4D-8ECB-49459B4B618F@pm.me> References: <555D18B0-4104-4A4D-8ECB-49459B4B618F@pm.me> Message-ID: > 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: