[Lightning-dev] Remove Description From Bolt11 Invoices

Mon Jan 31 15:10:22 UTC 2022

(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:
>
>    1. Which internal UserID is paying
>    2. Which Lightning Node is receiving a payment
>    3. Amount
>    4. 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/20220131/0b4903a4/attachment.html>