📅 Original date posted:2022-01-31
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220131/c1474c61/attachment.html>;
armdxxi [ARCHIVE] /
npub15h…3vytr
2023-06-09 13:05:04
in reply to nevent1q…c2ap
Author Public Key
npub15htd3gjk4un740ec6jsqz2mantd2j606qeqcmaffu5cxsgvfhqtqe3vytrPublished at
2023-06-09 13:05:04Event JSON
{
"id": "d662aa4e1c56d2f31d913f2272b24beb05c5210f8200f8905f73112195b2d979",
"pubkey": "a5d6d8a256af27eabf38d4a0012b7d9adaa969fa06418df529e530682189b816",
"created_at": 1686315904,
"kind": 1,
"tags": [
[
"e",
"8de0f6dfbc3fa515a02c2ab9c0ca197046da32b5940db00d48465aa48ecd7970",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2022-01-31\n📝 Original message:\nAll,\n\nIn 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\nThe 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\nThe 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\nKYC Node Verification\n\nCompanies 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\nGiven 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\nThis 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\nPayment Reason Aggregation\n\nOn 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\nA 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\nWhat they'd know solely on processing Bolt11 invoice data:\n\n- Which internal UserID is paying\n- Which Lightning Node is receiving a payment\n- Amount\n- Payment Reason\n\nThis 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\nThe 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\nGiven 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\nDescription Hash\n\nUsing the tagged field description hash h instead of description d might help but there are a few problems.\n\nFor 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\nA 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\nSo 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\nFurther, a salt would need to be added to descriptions for common payment reasons to not be guessed.\n\nIn 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\nSummary\n\nThere'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\nRegards,\narmdxxi\n\nLinks:\n[0] https://bitcoinmagazine.com/technical/bitcoin-aopp-and-the-swiss-travel-rule\n[1] https://web.archive.org/web/20210616100214/https://help.bottlepay.com/en/articles/5303125-why-and-how-do-i-verify-my-node\n[2] https://twitter.com/niftynei/status/1479154453777465344\n[3] https://blog.chainalysis.com/reports/lightning-network-support/\n[4] https://twitter.com/MattAhlborg/status/1435350678814302211\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220131/c1474c61/attachment.html\u003e",
"sig": "72fcef350a23e8a06d42bc6a7e7f219f0da41f08cbdad8ea01780bbe1960b474d2f3cf5d908c3ba220a24a4da301112f0271606a4c3280c71dc718d9e4a2dbbf"
}