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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
