2

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

From what I understand, after its payment it won't allow a 2nd payment of the invoice, so 3rd parties will know if this invoice was paid, but what more can they learn? (Keeping aside the social-engineering impersonations)

  • Does it affect -most importantly- the safety of the funds?
  • Does it negatively affect the privacy or something else?
  • Could the actual payer prove (cryptographically) that they were the one that paid the invoice?
3
+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.

1

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.

In order to have a more specific discussion I created an invoice:

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

and I decode the 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 would know that at this time a purchase took place
  • expiry: only relevant in the sense explained abouve
  • 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. However if a third party on the chosen route (which is also private) would - for whatever reason - know the preimage of the payment hash funds could be stolen. This is irrelevant as the routing node knows the payment hash anyway when participating in routing
  • signature: cryptographic signatures are supposed to be safe.

Therefor 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?

There is -afaik- 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. Also 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.