Zero-value invoices allow a payment recipient to share an invoice with no initial value. With this invoice, they can receive any amount of Bitcoin from a sender. A typical use case for zero-value invoices is to receive tips and donation payments. They are also useful in cases of refunds where a vendor wishes to send all or some portion of payment back to a payer. However, there is also a dangerous side to the use of zero-value invoices as they can be exploited by intermediate nodes on the payment route.

As a reminder, payments in the lightning network are routed from the sender to the receiver with an onion-routed package. Intermediate nodes on the route neither know the route's total length nor the payment's final receiver. They only know who their immediate predecessor is and have the relevant information to forward the payment to their successor on the route (i.e. the channel ID of the successor and the amount to forward). So if there is a malicious node involved in the payment, then they would be able to steal some of the funds.

Suppose Alice wants to send a tip of 10,000 satoshis to Carol who has a zero-value lightning invoice for collecting tips/donation on her website. However, since Carol and Alice do not have a channel open, Alice would have to route the payment through Bob who is malicious. So if Bob guesses that Carol's invoice is zero-valued, he can try to steal funds by sending Carol fewer satoshis (sats), say 50 sats, in exchange for the payment pre-image which he is supposed to get with 10,000 sats. And Carol who was not initially aware of the actual payment meant to be made would release the preimage after receiving the 50 sats.

If Bob had guessed incorrectly that the invoice was zero-value, not only does it cost Bob nothing to try to be malicious, but Alice cannot tell the difference between Bob trying to be malicious and any arbitrary person trying to be malicious and routing through Bob. So she can’t punish him. If she did, then anyone could force her to punish all of her neighbours by routing bad payments through them.

One way of preventing theft of funds through the use of zero-value invoices is by using Multipath Payments and ensuring that a payment address/secret is included in the payload of the payment. Since the value of the payment address/secret can't be guessed by intermediate nodes, zero-value invoices can be used safely. Please note that the payment address/secret is entirely different from the preimage - the receiver generates the preimage, but it is the sender that includes the payment secret at the point of making a multipath payment. You can read more on this implementation here

Another way of solving the potential theft problem is through the use of spontaneous payment options like Keysend where Carol would need to share her Lightning node's public key (instead of an invoice) so that donors like Alice can send a payment to her. As Keysend payments are encrypted, none of the nodes moving the payment can fully decipher the package ( or onion) and discover the preimage except the node whose public key is included in the keysend payment.

Zero-value Bolt 11 Invoices VS Bolt 12 Offer Invoices

Zero-value Bolt 11 invoices are ideal for tips and donations, however, they still have the limitations of regular Bolt 11 invoices in that they are only useable once. With Offers, a recipient can generate a single QR code invoice and receive payments as many times as possible. This is because an offer has enough information within it to retrieve a real invoice from the issuer of the offer. However, a commonality between Zero-value Bolt 11 invoices and Offers is that an Offer can also be zero-value, enabling the payer to set any amount they would like to send to the issuer of the offer.