Zero amount invoices have been around since the inception of invoices on the lightning network and are widely used for tips, among other things. At Suredbits, we use them as part of our refund mechanism. It turns out, however, that using zero amount invoices is not as trustless as a normal invoice-based payment. They are subject to attack from the last-hop – i.e. the receiving node’s peers – which is described in detail here Zero Amount Payments . I’ll recap what this attack looks like.

Suppose Alice is receiving live trade updates on a Suredbits WebSocket API. If she wants the option to cancel a subscription at any time and receive a refund for the remainder of her subscription, she must provide a zero amount invoice over the websocket so that Suredbits can pay her back a variable amount. If Alice has a channel open with Mike, who is malicious, then Suredbits might try to refund Alice 10,000 satoshis with Mike as their last hop. In this case if Mike were to guess that this 10,000 sat payment was to an amountless invoice, he might try and steal these funds by sending Alice fewer satoshis, say 10, in exchange for the payment pre-image, which he could then use to claim the 10,000 satoshis. 

Notice that if Mike guesses incorrectly (and this isn’t a zero amount invoice or he isn’t the last hop), not only does it not cost Mike anything to try the attack, but Alice cannot tell the difference between Mike trying to be malicious and any arbitrary person trying to be malicious and routing through Mike. So she can’t punish him. If she did, then anyone could force her to punish all of her neighbors by routing bad payments through them (for free).

What can Alice do to protect herself from this kind of attack?

The long-term answer is to use spontaneous payments, which are coming to the lightning network in the next version and allow for invoiceless payments of arbitrary amounts. But what if Alice is worried about this attack vector today and wants to use Suredbits’ refund feature? There are some options available: 

  1. She can open a channel directly with Suredbits. This avoids the need to route in general and has the added benefit of avoiding fees and latency.
  2. She can peer only with trusted neighbors, disconnecting from all the “Mikes” she is connected to.
  3. She can operate two lightning nodes A1 and A2 where A1 is just a standard, well-connected node, and A2 is only connected to A1 where she uses A2 to accept all of her incoming payments. This approach would make it so that she (A1) is always the last hop and hence safer from the exploit (though it should be noted that this isn’t completely safe as her neighbors can still guess that A2 is the final node since it is only connected to A1, but this is certainly even safer than a usual setup).
  4. Lastly, she can add a condition to her lightning node’s payment processing, saying that she won’t accept zero-amount invoice payment either under a certain amount or without her (or one of her bots’) permission.

Suredbits could also take action to remove this vulnerability by adding a round of interaction on the WebSocket wherein an unsubscribe message would contain within it an invoice which had an amount specified. This amount would have to be some near lower-bound (refund/2 < amount < refund) on the amount of time left on the subscription being refunded.  That would allow us to simply over-pay the invoice with the correct refund amount. However, we do not plan on implementing this in the near-term as it would create unnecessary complexity for our users. 

Zero amount invoices should be deprecated in favor of spontaneous payments which are not vulnerable to the last-hop attack and are coming soon. Until then, lightning network users should be mindful of their use of such invoices and consider mitigating their risks by avoiding the malicious Mikes out there or by using invoices with (lower bound) amounts specified.

Contact us @Suredbits

Contact Nadav @Nadav_Kohen

All of our API services are built using Lightning technology and the Lightning Network. All API services are live on Bitcoin’s mainnet. Our fully customizable data service allows customers to stream as much or as little data as they wish and pay using bitcoin.

You can connect to our Lightning node at the url:

To learn more about how our Lightning APIs work please visit our API documentation or checkout our new websocket playground to start exploring custom data feeds.

If you are a company or cryptocurrency exchange interested in learning more about how Lightning can help grow your business, contact us at [email protected].