Proposal: Anonymous Invoices

[microlancer]

Anonymous Invoices

Lightning invoices have the payment destination encoded in the invoice data. This means that if you post an invoice, let’s say, in forum A, and then another invoice in forum B, then anyone can easily determine that the destination is the same node and therefore know that they are likely meant for the same receiving identity.

In Bitcoin addresses, because new addresses can be generated in the same wallet, you can post two addresses in forums A and B and nobody can easily know they are the same receiving identity.

This is a proposal to hide the receiving node information by creating a lightning invoice payload that, through the use of encoding by the public key of a required intermediate node, only that node will be capable of decoding the final destination.

Here is an example of a standard BOLT11 invoice:

lnbc1u1p0mgukvpp5cf9uce7l3d7fmmk57yk2htdmwntwmyfn339feq8mhfcatqfk4g8qdqvv3jhqmmnd96qcqzpgxqyz5vqsp5zdty4pkxp9ku2qt3lwhdlg7n7tgh07d0pd9xzu4u9mwsuhtvrjlq9qy9qsquqr7t0574ahpxua8pnc3qk93v9nh9dllzrlvutap5d0zmumwgj6s3du8mrn3c4ugeajfvyztx9u79cr7jt5tllem98hmmlf3zj8qxkqq4r4p9l

The payee can publically be decoded to:

03295d2e292565743a40bd44da227a820f8730877bc3dfadebade8785bcf355258

Normally, this invoice can be paid using any route discovered by the lightning node which is initiating the payment. However, with an Anonymized Invoice, the payee string will be encoded and an intermediate node will be specified which will perform the 2nd routing half of the payment request.

We can select any node to be a required intermediate of the payment request. In this example, we select ACINQ to be the intermediate node. ACINQ has a public key of 03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f and we can use the ACINQ public key to bi-directionally encrypt the actual payee (03295d…). On the surface of the public invoice, the actual payee is now encrypted. A new BOLT specification would be required to encode the intermediate payee, and such nodes will need to be able to handle these types of invoices slightly differently, and decrypt the payee information.

When a payment is made to this invoice, a route with a destination of ACINQ will be determined by the paying node. However, the HTLC will continue to the full destination which is only known by ACINQ when it receives the invoice it will be able to decode the actual payee using the node's own private key.

While standard payment routing does have the ability to hide the "true destination" (onion routing) between hops, the publicly posted invoices (raw Lightning invoice strings) do not have that information encrypted.

One downside to this proposal which makes it less anonymous, is that the intermediate node actually will have the destination information. However, as long as the intermediate node is not leaking information, or the intermediate node is one that is trusted (for example, perhaps maintained by the entity making the request), then the final destination cannot easily be associated with a single shared identity. In particular, if the intermediate node is very well-known and popular, and used as an intermediate node for many payments, it will be harder to correlate different payments.

When an invoice (in the current BOLT standard) is being made for a specific node that is very rare, it is much easier to correlate. For example invoices made to the node "Jim Smith's raspberry pi node in NY" and then posted on several forums, one could much more easily correlate to Jim Smith, than an Anonymous Invoice generated to use ACINQ as an intermediary, a very large and popular node.

This solution is not perfect, but has some privacy advantages over the existing "raw payee node" mechanism of lightning invoices.

[t-bast]

Lightning invoices have the payment destination encoded in the invoice data. This means that if you post an invoice, let’s say, in forum A, and then another invoice in forum B, then anyone can easily determine that the destination is the same node and therefore know that they are likely meant for the same receiving identity.

Have you read #765?

It does exactly what you want, it will allow recipients to sign each invoice with a different, un-linkable key, and force specific (blinded) paths for the payment.

[microlancer]

Thank you, will close this.