đź“… Original date posted:2022-02-01
đź“ť Original message:
Martin,
Thank you for the thoughtful analysis and game theory on this.
> impossibility to prove payment for goods or services making arbitration hard or impossible
Preimages and invoices still prove payment to a specific node. Specific items, maybe not, but maybe a use case for keeping description hash for this.
> 0. exchange doesn't enforce description
> 1. exchange does enforce description
If I understand your case 0 and 1 distinctions, the envisioned scenario is that this AOPP-style regulation gets restrictive enough that nobody can use regulated custodians to make payments. Their only option is to withdraw to their node and then make a payment from there. Thus, their payments and spending habits are protected.
Why do we need to comply with extreme node level KYC enforcement to make this the case? The enforcement won’t stop with the scenario you’ve described if everyone is complying and supporting these regulations in the first place. 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.
> Also node IDs could be rotated.
How so? Close down all channels, shut down node, coinjoining utxo’s and spin up a new one? That would be quite a costly procedure, both in time & effort as well as monetarily. Especially if this were to occur on a large scale.
When we’re talking about users still using custodians, the barrier of entry for managing all this is even higher.
> "KYC" of a private node ID is completely meaningless
This will be the realization of the regulators as well. 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.
> 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. Ideally, it’s like you’ve said, “popular public node”. What about everyone else?
> it could be the case here that it's a good way to turn regulations against the regulators and it could outweigh the cons.
It’s an interesting scenario and thought process to see how to turn it positive, but in the interim - this is happening now. There is not a hard & fast rule that no custodian is processing anything except to the user’s (assumingly) private nodes. 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?
Regards,
armdxxi
On 31 Jan 2022, at 9:10, Martin Habovštiak wrote:
> (sorry for double message, wrong button)
>
> Hi,
>
> I object to the idea that AOPP-like verification is harmful *to lightning*, quite contrary, it's beneficial! Also removing description creates another problem: impossibility to prove payment for goods or services making arbitration hard or impossible.
>
> Why it's beneficial?
>
> Suppose there's a dissident in a dictatorship country wanting to buy banned goods. He pays using LN. There are two possibilities:
> 0. exchange doesn't enforce description
> 1. exchange does enforce description
>
> Let's look at case 0:
> The dissident, who happens to not be that knowledgeable about security buys sats at an exchange and inputs the destination invoice from whoever he pays directly into the exchange. The exchange logs this along with the identity. Some time later the node ID being paid for banned goods leaks (very likely for public nodes) and the tyrants use this to track down dissidents. The dissident is screwed.
>
> Case 1:
> The dissident withdraws to his non-custodial wallet (can't do anything else) which he then uses to pay. The exchange can not possibly see where the payment went from non-custodial wallet or if it was even sent away. Recipients don't know identities of senders so no matter what information leaks, it's impossible to link the payment.
>
> The biggest real problem with the enforcement is the fact that invoices leak txids of private channels even though they shouldn't have to. *This* needs to be fixed, really. Also node IDs could be rotated.
>
> Assuming it's fixed, "KYC" of a private node ID is completely meaningless. The exchange can not see where the sats ultimately end up - either LN or chain. It's essentially equivalent to assigning meaningless random number to each transaction.
>
> This assumes "private" channels but has a simple workaround for public nodes too. 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.
>
> Note that this whole reasoning doesn't apply to BTC chain as addresses don't have such strong privacy properties but could be applied to e.g. Monero (maybe a bit weaker guarantee; not endorsing it).
>
> I'm not saying that we should (not) proactively support these efforts, since accepting regulations is bad precedent but it could be the case here that it's a good way to turn regulations against the regulators and it could outweigh the cons.
>
> Hope I'm clear enough. Cheers!
> Martin
>
> On Mon, Jan 31, 2022, 06:07 armdxxi via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> All,
>>
>> In light of recent AOPP concerns[0] where custodial users have to sign a message from an address to prove that it is theirs when withdrawing from highly regulated exchanges, I thought it was important to bring up that this is happening in the Lightning space as well.
>>
>> The tagged field d provides both payers and payees with a description of what the transaction is for. When a Lightning Node creates a BOLT11 invoice with a description, this is signed. The signature verification process validates that it came from a specific node and that it is unaltered.
>>
>> The problem is that this is being exploited by bad actors in the regulated space. Unsuspecting users are going along with it not knowing the repercussions.
>>
>> KYC Node Verification
>>
>> Companies like Bottlepay[1] are forcing some users to verify their node by creating a specialized invoice. They ask the user to put PII in the description and give the signed invoice to the service. Afterwards, a database of KYC'd users and their nodes may be stored and shared with 3rd parties, regulators, and governments.
>>
>> Given that the Lightning Network is a reputation-based system without an easy way to handle rotations, this has lasting effects if this practice were to scale out to all providers. At least with AOPP, one may spin up a new on-chain address with ease and attempt to mitigate linkage via coinjoin.
>>
>> This alone is enough to recommend wallet devs to remove the ability for users to unknowingly sign statements with their node. Just like with the widespread removal of AOPP from hardware/software wallets, exchanges may stop expecting that users are capable of handing over this information with ease.
>>
>> Payment Reason Aggregation
>>
>> On the payment receiver side, a user may add a description for their reference later on. In an ideal world, only the payer and payee are the ones that know the reason for the payment. However, given the current reliance on custodians today, these 3rd parties can see and store this information.
>>
>> A good thread[2] highlights some of these concerns. If exchanges are relaying invoices to chain analytic companies[3], this can be pretty revealing in aggregation.
>>
>> What they'd know solely on processing Bolt11 invoice data:
>>
>> - Which internal UserID is paying
>> - Which Lightning Node is receiving a payment
>> - Amount
>> - Payment Reason
>>
>> This information collected in bulk will allow them to map out risk scores across the network. These risk scores will lead to censorship problems. Additionally, they may share suspected node owners and their known transactions with malicious parties.
>>
>> The onus is on the receiver to not create invoices that reveal personal information. But how is a user supposed to know that it could end up being collected by 3rd party analytic aggregators? In the end, users may just want to tag the invoice and store it internally for their reference. Even custodial wallet developers don't realize the repercussions to invoice descriptions[4].
>>
>> Given this, one suggestion I have is to clearly communicate that the information users put in invoices can be verified by 3rd parties. Ideally wallet devs should remove description completely.
>>
>> Description Hash
>>
>> Using the tagged field description hash h instead of description d might help but there are a few problems.
>>
>> For one, there's a transport problem that's not handled by the BOLT11 specification. From the spec: the transport mechanism for the description in that case is transport specific and not defined here.
>>
>> A payer's wallet client needs to be able to receive two values from the payee now. Both the invoice with the description hash and the description text itself. This could happen via QR code in the typical flow today, but the problem is that information is still parsed by the payer's wallet.
>>
>> So if the payer's wallet is a custodian, the custodian is still capable of knowing and relaying both Bolt11 Invoice and the unhashed description. The benefit is that they may choose not to collect this description information. Though it still leaves the door open for bad actors.
>>
>> Further, a salt would need to be added to descriptions for common payment reasons to not be guessed.
>>
>> In the end, description hash is better than description, but there are UX considerations that may not solve the problem. My suggestion is to save the description to the wallet database instead of putting it in the invoice. Payers should be provided with a similar description text box that may be saved in their database. This gives both users the ability to conceal the real reason even if their wallet is a custodian.
>>
>> Summary
>>
>> There's enough exploitation currently happening with Bolt11 invoices that we should be concerned about this. My recommendation is to remove the ability for users to shoot themselves in the foot. This can happen at the application layer today by removing descriptions from wallets. The lack of description support will help hinder the ability for mass surveillance in the Lightning space.
>>
>> Regards,
>> armdxxi
>>
>> Links:
>> [0] https://bitcoinmagazine.com/technical/bitcoin-aopp-and-the-swiss-travel-rule
>> [1] https://web.archive.org/web/20210616100214/https://help.bottlepay.com/en/articles/5303125-why-and-how-do-i-verify-my-node
>> [2] https://twitter.com/niftynei/status/1479154453777465344
>> [3] https://blog.chainalysis.com/reports/lightning-network-support/
>> [4] https://twitter.com/MattAhlborg/status/1435350678814302211
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220201/e31ef62b/attachment-0001.html>;
armdxxi [ARCHIVE] /
npub15h…3vytr
2023-06-09 13:05:05
in reply to nevent1q…75n8
Author Public Key
npub15htd3gjk4un740ec6jsqz2mantd2j606qeqcmaffu5cxsgvfhqtqe3vytrPublished at
2023-06-09 13:05:05Event JSON
{
"id": "fc41fcb44e3449c7a81cfd20a167406be78e205a8a2b710a280ecdc9318bcf91",
"pubkey": "a5d6d8a256af27eabf38d4a0012b7d9adaa969fa06418df529e530682189b816",
"created_at": 1686315905,
"kind": 1,
"tags": [
[
"e",
"805aac32ee8ccf8a24c85af961457e821573e6fb4f7000802f5f5edc216ae2cd",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2022-02-01\n📝 Original message:\nMartin,\n\nThank you for the thoughtful analysis and game theory on this.\n\n\u003e impossibility to prove payment for goods or services making arbitration hard or impossible\n\nPreimages and invoices still prove payment to a specific node. Specific items, maybe not, but maybe a use case for keeping description hash for this.\n\n\u003e 0. exchange doesn't enforce description\n\u003e 1. exchange does enforce description\n\nIf I understand your case 0 and 1 distinctions, the envisioned scenario is that this AOPP-style regulation gets restrictive enough that nobody can use regulated custodians to make payments. Their only option is to withdraw to their node and then make a payment from there. Thus, their payments and spending habits are protected.\n\nWhy do we need to comply with extreme node level KYC enforcement to make this the case? The enforcement won’t stop with the scenario you’ve described if everyone is complying and supporting these regulations in the first place. 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.\n\n\u003e Also node IDs could be rotated.\n\nHow so? Close down all channels, shut down node, coinjoining utxo’s and spin up a new one? That would be quite a costly procedure, both in time \u0026 effort as well as monetarily. Especially if this were to occur on a large scale.\n\nWhen we’re talking about users still using custodians, the barrier of entry for managing all this is even higher.\n\n\u003e \"KYC\" of a private node ID is completely meaningless\n\nThis will be the realization of the regulators as well. 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.\n\n\u003e 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.\n\nI think this is a good thing to do but if not done correctly, there can be enough correlations to break this down. Ideally, it’s like you’ve said, “popular public node”. What about everyone else?\n\n\u003e it could be the case here that it's a good way to turn regulations against the regulators and it could outweigh the cons.\n\nIt’s an interesting scenario and thought process to see how to turn it positive, but in the interim - this is happening now. There is not a hard \u0026 fast rule that no custodian is processing anything except to the user’s (assumingly) private nodes. 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?\n\nRegards,\narmdxxi\n\nOn 31 Jan 2022, at 9:10, Martin Habovštiak wrote:\n\n\u003e (sorry for double message, wrong button)\n\u003e\n\u003e Hi,\n\u003e\n\u003e I object to the idea that AOPP-like verification is harmful *to lightning*, quite contrary, it's beneficial! Also removing description creates another problem: impossibility to prove payment for goods or services making arbitration hard or impossible.\n\u003e\n\u003e Why it's beneficial?\n\u003e\n\u003e Suppose there's a dissident in a dictatorship country wanting to buy banned goods. He pays using LN. There are two possibilities:\n\u003e 0. exchange doesn't enforce description\n\u003e 1. exchange does enforce description\n\u003e\n\u003e Let's look at case 0:\n\u003e The dissident, who happens to not be that knowledgeable about security buys sats at an exchange and inputs the destination invoice from whoever he pays directly into the exchange. The exchange logs this along with the identity. Some time later the node ID being paid for banned goods leaks (very likely for public nodes) and the tyrants use this to track down dissidents. The dissident is screwed.\n\u003e\n\u003e Case 1:\n\u003e The dissident withdraws to his non-custodial wallet (can't do anything else) which he then uses to pay. The exchange can not possibly see where the payment went from non-custodial wallet or if it was even sent away. Recipients don't know identities of senders so no matter what information leaks, it's impossible to link the payment.\n\u003e\n\u003e The biggest real problem with the enforcement is the fact that invoices leak txids of private channels even though they shouldn't have to. *This* needs to be fixed, really. Also node IDs could be rotated.\n\u003e\n\u003e Assuming it's fixed, \"KYC\" of a private node ID is completely meaningless. The exchange can not see where the sats ultimately end up - either LN or chain. It's essentially equivalent to assigning meaningless random number to each transaction.\n\u003e\n\u003e This assumes \"private\" channels but has a simple workaround for public nodes too. 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.\n\u003e\n\u003e Note that this whole reasoning doesn't apply to BTC chain as addresses don't have such strong privacy properties but could be applied to e.g. Monero (maybe a bit weaker guarantee; not endorsing it).\n\u003e\n\u003e I'm not saying that we should (not) proactively support these efforts, since accepting regulations is bad precedent but it could be the case here that it's a good way to turn regulations against the regulators and it could outweigh the cons.\n\u003e\n\u003e Hope I'm clear enough. Cheers!\n\u003e Martin\n\u003e\n\u003e On Mon, Jan 31, 2022, 06:07 armdxxi via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e All,\n\u003e\u003e\n\u003e\u003e In light of recent AOPP concerns[0] where custodial users have to sign a message from an address to prove that it is theirs when withdrawing from highly regulated exchanges, I thought it was important to bring up that this is happening in the Lightning space as well.\n\u003e\u003e\n\u003e\u003e The tagged field d provides both payers and payees with a description of what the transaction is for. When a Lightning Node creates a BOLT11 invoice with a description, this is signed. The signature verification process validates that it came from a specific node and that it is unaltered.\n\u003e\u003e\n\u003e\u003e The problem is that this is being exploited by bad actors in the regulated space. Unsuspecting users are going along with it not knowing the repercussions.\n\u003e\u003e\n\u003e\u003e KYC Node Verification\n\u003e\u003e\n\u003e\u003e Companies like Bottlepay[1] are forcing some users to verify their node by creating a specialized invoice. They ask the user to put PII in the description and give the signed invoice to the service. Afterwards, a database of KYC'd users and their nodes may be stored and shared with 3rd parties, regulators, and governments.\n\u003e\u003e\n\u003e\u003e Given that the Lightning Network is a reputation-based system without an easy way to handle rotations, this has lasting effects if this practice were to scale out to all providers. At least with AOPP, one may spin up a new on-chain address with ease and attempt to mitigate linkage via coinjoin.\n\u003e\u003e\n\u003e\u003e This alone is enough to recommend wallet devs to remove the ability for users to unknowingly sign statements with their node. Just like with the widespread removal of AOPP from hardware/software wallets, exchanges may stop expecting that users are capable of handing over this information with ease.\n\u003e\u003e\n\u003e\u003e Payment Reason Aggregation\n\u003e\u003e\n\u003e\u003e On the payment receiver side, a user may add a description for their reference later on. In an ideal world, only the payer and payee are the ones that know the reason for the payment. However, given the current reliance on custodians today, these 3rd parties can see and store this information.\n\u003e\u003e\n\u003e\u003e A good thread[2] highlights some of these concerns. If exchanges are relaying invoices to chain analytic companies[3], this can be pretty revealing in aggregation.\n\u003e\u003e\n\u003e\u003e What they'd know solely on processing Bolt11 invoice data:\n\u003e\u003e\n\u003e\u003e - Which internal UserID is paying\n\u003e\u003e - Which Lightning Node is receiving a payment\n\u003e\u003e - Amount\n\u003e\u003e - Payment Reason\n\u003e\u003e\n\u003e\u003e This information collected in bulk will allow them to map out risk scores across the network. These risk scores will lead to censorship problems. Additionally, they may share suspected node owners and their known transactions with malicious parties.\n\u003e\u003e\n\u003e\u003e The onus is on the receiver to not create invoices that reveal personal information. But how is a user supposed to know that it could end up being collected by 3rd party analytic aggregators? In the end, users may just want to tag the invoice and store it internally for their reference. Even custodial wallet developers don't realize the repercussions to invoice descriptions[4].\n\u003e\u003e\n\u003e\u003e Given this, one suggestion I have is to clearly communicate that the information users put in invoices can be verified by 3rd parties. Ideally wallet devs should remove description completely.\n\u003e\u003e\n\u003e\u003e Description Hash\n\u003e\u003e\n\u003e\u003e Using the tagged field description hash h instead of description d might help but there are a few problems.\n\u003e\u003e\n\u003e\u003e For one, there's a transport problem that's not handled by the BOLT11 specification. From the spec: the transport mechanism for the description in that case is transport specific and not defined here.\n\u003e\u003e\n\u003e\u003e A payer's wallet client needs to be able to receive two values from the payee now. Both the invoice with the description hash and the description text itself. This could happen via QR code in the typical flow today, but the problem is that information is still parsed by the payer's wallet.\n\u003e\u003e\n\u003e\u003e So if the payer's wallet is a custodian, the custodian is still capable of knowing and relaying both Bolt11 Invoice and the unhashed description. The benefit is that they may choose not to collect this description information. Though it still leaves the door open for bad actors.\n\u003e\u003e\n\u003e\u003e Further, a salt would need to be added to descriptions for common payment reasons to not be guessed.\n\u003e\u003e\n\u003e\u003e In the end, description hash is better than description, but there are UX considerations that may not solve the problem. My suggestion is to save the description to the wallet database instead of putting it in the invoice. Payers should be provided with a similar description text box that may be saved in their database. This gives both users the ability to conceal the real reason even if their wallet is a custodian.\n\u003e\u003e\n\u003e\u003e Summary\n\u003e\u003e\n\u003e\u003e There's enough exploitation currently happening with Bolt11 invoices that we should be concerned about this. My recommendation is to remove the ability for users to shoot themselves in the foot. This can happen at the application layer today by removing descriptions from wallets. The lack of description support will help hinder the ability for mass surveillance in the Lightning space.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e armdxxi\n\u003e\u003e\n\u003e\u003e Links:\n\u003e\u003e [0] https://bitcoinmagazine.com/technical/bitcoin-aopp-and-the-swiss-travel-rule\n\u003e\u003e [1] https://web.archive.org/web/20210616100214/https://help.bottlepay.com/en/articles/5303125-why-and-how-do-i-verify-my-node\n\u003e\u003e [2] https://twitter.com/niftynei/status/1479154453777465344\n\u003e\u003e [3] https://blog.chainalysis.com/reports/lightning-network-support/\n\u003e\u003e [4] https://twitter.com/MattAhlborg/status/1435350678814302211\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220201/e31ef62b/attachment-0001.html\u003e",
"sig": "e4056a03bad961af5b61ea9aae53d3d34824e677bf8ed27295efe1f940b17eed061bca6ed2972acab3f69b44f3fe76e9a9923d6ce429a21cbf8479399ef7784d"
}