4

What are the perils of publicizing a LN invoice either before or after its payment?

From what I understand, after its payment the second payment of the invoice cannot be done. Other than the fact that the invoice was already paid, what could the third parties learn from a lightning invoice?

Keeping aside social-engineering impersonations:

  • Can the safety of the funds by affected any any information published in the invoice?
  • In what way publishing such an invoice may affect privacy of the transacting parties?
  • Could the payer prove (cryptographically) that they were the one that paid the invoice?
6
+50

Does it affect -most importantly- the safety of the funds?

It does not. Funds are not affected by publishing a LN invoice.

Does it negatively affect the privacy or something else?

If a lightning invoice is published, 3rd parties may learn some semi-private information about the payer and payee. First and foremost, they learn the amount that was paid and to which node that amount was paid. Since an invoice can contain a short description, they may also learn what the payment was for by reading the description.

LN invoices also may contain specific routing information, particularly for private nodes. Revealing a LN invoice may also reveal a private node's existence, public key, and a channel id of that node.

Could the actual payer prove (cryptographically) that they were the one that paid the invoice?

Anyone in the route (including the payer) can prove that they were in the route by revealing the payment preimage. I'm not sure whether the payer can prove that he was the payer, but he can prove that he was involved in the payment as either a forwarder or as the payer.

However if the payer is involved in a dispute with the payee, he can prove that he paid by presenting the payment preimage.

3

Before answering your questions in detail let me state that as far as I know third parties cannot know if the invoice was paid after it was expired. Although I like Andrew Chow's answer I think I have some more bits to add.

Take a look at an invoice that I created:

user@computer:~$ lightning-cli invoice 10000000 bitcoinstackexchage explainInvoices 3600000
{
  "payment_hash": "0bc8bec5d84eb11df30db8752b23b4ab813a6f78732db94df9d0ca3d251d19bc", 
  "expires_at": 1540772525, 
  "bolt11": "lnbc100u1pde7epdpp5p0yta3wcf6c3mucdhp6jkga54wqn5mmcwvkmjn0e6r9r6fgarx7qdqcv4u8qmrpd9hyjmnkda5kxetnxq9rdm5qcqp2yzl5v00cdl9rq5egsfgknerxecczdzxldz9vgwnwcxw9snn6mst85z4gqd4ex59s0kzhzxnwyrdc88kfgkq908medwwd63pqqjnkr2gp6d6w2s"
}

I decoded its bolt11 string here:

user@computer:~$ lightning-cli decodepay lnbc100u1pde7epdpp5p0yta3wcf6c3mucdhp6jkga54wqn5mmcwvkmjn0e6r9r6fgarx7qdqcv4u8qmrpd9hyjmnkda5kxetnxq9rdm5qcqp2yzl5v00cdl9rq5egsfgknerxecczdzxldz9vgwnwcxw9snn6mst85z4gqd4ex59s0kzhzxnwyrdc88kfgkq908medwwd63pqqjnkr2gp6d6w2s
{
  "currency": "bc", 
  "created_at": 1537172525, 
  "expiry": 3600000, 
  "payee": "03efccf2c383d7bf340da9a3f02e2c23104a0e4fe8ac1a880c8e2dc92fbdacd9df", 
  "msatoshi": 10000000, 
  "description": "explainInvoices", 
  "min_final_cltv_expiry": 10, 
  "payment_hash": "0bc8bec5d84eb11df30db8752b23b4ab813a6f78732db94df9d0ca3d251d19bc", 
  "signature": "3044022020bf463df86fca305328825169e466ce302688df688ac43a6ec19c584e7adc1602207a0aa8036b9350b07d85711a6e20db839ec94580579f796b9cdd442004a761a9"
}

As you can see there is not that much sensitive information in here:

  • currency: bc --> no big deal
  • created_at: --> obviously dates might be interesting with relation to privacy. The timestamp is created by your system clock. Assuming no manipulation of the clock one learns that at this time the purchase took place.
  • expiry: only relevant in the sense explained above
  • payee: well it reveals you for obvious reasons. So you make public that at a certain time for a certain reason (c.f. description) you expect a payment of a certain amount (c.f. amount).
  • msatoshi: as payee
  • description: here comes all the social engineering which you didn't ask for
  • min_final_cltv_expiry: I would assume no problem here unless you can somehow afford a 51% attack and rewind some blocks while initiating a payment
  • payment_hash: as long as the hash function is secure (which is the base assumption of the lightning network) no one could do anything with the payment hash. If, for whatever reason, a third party on the chosen route (which is also private) knows the preimage of the payment hash funds could be stolen. However, this is irrelevant as the routing node knows the payment hash anyway.
  • signature: cryptographic signatures are supposed to be safe.

Therefore I conclude similarly as Andrew:

Does it affect -most importantly- the safety of the funds?

I don't see in which way it would.

Does it negatively affect the privacy or something else?

Other than the mentioned points which belong more to social engineering I would say no.

Could the actual payer prove (cryptographically) that they were the one that paid the invoice?

AFAIK there is only one way to prove that you paid an invoice. The node needs to have only one channel (during the relevant timeframe of invoice creation and expiry / received payment) which can be looked up on the blockchain and needs to provide the preimage. Moreover we need to assume that no one on the route publishes the preimage. Otherwise identifying the payer of an invoice seems impossible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.