Martin Habovštiak [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-01 📝 Original message: > Specific items, maybe ...
đź“… 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>;
đź“ť 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>;