Would sharing r_preimage be a security risk?

[icebaker]

I'm trying to learn more about the implications of the fields r_preimage and r_hash from lnrpc.Invoice:

r_preimage:

The hex-encoded preimage (32 byte) which will allow settling an incoming HTLC payable to this preimage.

r_hash:

The hash of the preimage.

From the Making Payments page:

All payments along the route are made to this hash, and can only be claimed if the preimage is revealed. In case the preimage is not revealed, the payment goes back to its sender.

So, let's say I create an invoice and somehow leak the r_preimage, like sharing accidentally in a message, creating a public gist, committing it to a public git repository, etc.

Could someone use the r_preimage to exploit me somehow? e.g., fraudulently "pay" the Invoice?

Going further: Would sharing any of the fields from the lnrpc.Invoice​ expose me to this kind of risk?

[ellemouton]

Hi @icebaker,

Yes, sharing r_preimage is not a good idea. In LN world, being able to show an invoice (with the hash) along with the pre-image (which hashes to that hash) is taken as proof-of-payment.

With regards to other parts of the Invoice - none of the other parts are as big of a risk per-say since you are in any case putting most of those fields in an invoice that you will share with the person trying to pay you. But you dont necessarily want to share a single invoice with the world since something like payment_addr should really only ever be seen by the person trying to pay you. Further more, if you have some unannounced ("private") channels, then those will be in the invoice hop-hints and you don't necessarily want the world to know about your unannounced channels (although nothing stops the payee from sharing those with the world)

[icebaker]

Hi @ellemouton, thanks for replying! This is very helpful information.

So, for payment_addr and some other fields, the risks are more related to privacy, as sharing them may reduce the barriers for someone to track your node. Got it.

Trying to expand a bit to understand the r_preimage potential risks:

If I expose the r_preimage, someone could try to deceive me by communicating that they paid for something they didn't.

Example: Suppose I sell apples. I generate an invoice for an apple and leak the r_preimage. Someone uses this information to "pay" the invoice, and as the person has the r_preimage, I can't prove that they didn't actually pay the invoice. Even with me not receiving satoshis in my wallet, they could claim a failure in the network, and I would have no way of proving otherwise. So, I may deliver the apple to this fraudulent buyer.

So, my reasoning:

a) The risk is not being able to prove that someone didn't pay for the invoice, as they have the r_preimage, and potentially delivering something (e.g., the apple) that I shouldn't deliver. No actual satoshis are being moved in the network, no channel balances are changed, etc. It would be more like a social engineering thing.

b) If I generate a random invoice and leak the data, the worse that could happen is someone claiming a payment. As I don't care about the invoice, and I won't receive any value, and the person won't receive anything as well, that's nothing to be concerned about here.

c) The r_preimage is connected to its invoice only, and its sole purpose is to provide proof of payment. There's no way someone could use that to manipulate other invoices or perform any action on my node.

Does my reasoning make sense?

[ellemouton]

Actually, someone could technically steal money that belongs to you:

• let's say you generate an invoice with a preimage
• The preimage is leaked and node M (some random node) get's ahold of it
• You give node A your invoice so that they can pay it
• A now constructs a route to you that commits to the hash of the pre-image. They choose a route that has M as one of the hops
• Now, since M has the pre-image, then can "settle" the chain of htlc's back to A.
• Now A has a valid proof of payment but you never actually got paid! M has essentially stolen your money!

[icebaker]

Oh, that makes sense! Thanks for the example.

So, there are risks for an unsettled invoice, but once it is settled, it no longer matters. I assume there's no harm someone could do with the r_preimage after the payment is already settled, right?

[ellemouton]

technically yes, no money can be stolen from you (the node that created the pre-image and invoice) but if you are a merchant, then money could be stolen from your customers:

• you create an invoice
• A pays the invoice
• you release pre-image to the wild
• B (who got a hold of the invoice) now comes to you and demands the product they paid for (even though it was not them who paid for it)
• You release the product since B showed you proof of payment.
• A comes to you and demands the product but now you refuse since you already gave it away.
• A is an unhappy customer

So I would say, only once the pre-image has been settled, and the exchange of goods has taken place is it safe to share the pre-image with the world

[icebaker]

Got it.

Thank you very much for the explanation!