Author: Lorenzo
Source: https://www.voltage.cloud/blog/how-async-payments-on-lightning-network-work
Originally published in October 2023. The BOLT12 specification was merged into BOLT in September 2024.
introduction
The Lightning Network aims to be a solution for scaling Bitcoin's transaction throughput. However, as we delve deeper into the details of the Lightning Network, we're discovering areas where improvements are still needed. One notable area is the concept of "asynchronous payments"—a feature that, if implemented, could significantly improve the payment process and user experience.
Traditional on-chain Bitcoin payments are incredibly simple because of their asynchronous nature. Let's use an example to illustrate: Imagine Alice wants to pay Bob for guitar lessons. She visits Bob's social media profile and sees a Bitcoin address in his profile. To send a payment to Bob, Alice simply copies this address, pastes it into the recipient field in her Bitcoin wallet, and clicks "Send." This transaction is queued and confirmed by the Bitcoin blockchain. When Bob opens his wallet, he'll see an additional payment from Alice.
However, if Alice wants to pay Bob via the Lightning Network, the user experience is different. When making a payment, both the sender and the receiver must be online and exchange information.
Although it cannot be said to be absolutely perfect, the difference here lays the foundation for us to explain synchronous payments and asynchronous payments in the Lightning Network.
Lightning Network Payment Overview
To understand the concept of asynchronous payments, it’s helpful to first understand how payments are implemented in the Lightning Network.
On the Lightning Network, if Alice wants to send a payment to Bob, she must first request an invoice from Bob. This means Bob must actively open his Lightning wallet and generate an invoice for Alice's payment. Unlike traditional Bitcoin addresses, Lightning Network invoices are one-time use. Paying the same invoice multiple times could result in the sender losing funds.
(Translator's note: Although Bitcoin addresses can be reused, address reuse is a bad habit that compromises the privacy of the address owner. Double-paying an invoice poses a risk to the sender because after a payment is completed, the hash preimage that ensures the security of the payment is exposed, and an intermediary node that is not the recipient may also receive the second payment. For this reason, reusing invoices is also unsafe for the recipient.)
After receiving Bob's invoice, Alice uses her Lightning wallet to send a payment based on the invoice information. Behind the scenes, her payment traverses a series of Lightning channels until it reaches Bob's node (controlled by his Lightning wallet). Upon receiving the payment, Bob's node sends back a receipt. This receipt ensures that each intermediate node receives its fee and assures Alice that the payment was successful. If Bob's node is offline (and fails to send back a receipt) when the payment arrives, the payment is left hanging, unable to complete. While the Lightning Network protocol ensures that no one loses funds, it also presents a user experience challenge, as maintaining a continuous online state is difficult, especially on mobile devices.
In summary, Lightning Network payments face two synchronicity barriers:
- The recipient must be invited to generate an invoice;
- The recipient must be online when the payer sends the payment.
Processing asynchronous payments
Effects of asynchronous payments
Implementing asynchronous payments within the Lightning Network means payments can be made even if the recipient is offline. An intermediary node securely holds the payment and delivers it only when the recipient is reconnected to the network and able to receive it.
Simple method
At first glance, making Lightning payments asynchronous seems easy. The invoice exchange problem can be solved by having Bob's node generate many invoices in advance, store them on a third-party server, and then have the server deliver the invoices upon request. The payment confirmation problem can be solved by having the last node in the payment forwarding path temporarily hold the payment until Bob's node comes online.
However, these approaches have numerous problems. The most obvious one is the introduction of trust into a payment system designed to be trustless. The recipient must trust the "custodian" of their invoice to provide honest service. Another issue is that invoices can expire. Finally, because the payment is suspended in mid-air, all nodes along the payment forwarding path must lock up a portion of their liquidity until Bob returns online or the invoice expires. This is a negative outcome, as forwarding nodes need to manage their liquidity efficiently, and locking up liquidity for an indeterminate period of time is inefficient.
Can we do better?
Back in 2021, Matt Corallo proposed a compromise that could improve asynchronous payments. This would require the use of " LNURLs ," with both the sender and receiver using a Lightning Service Provider (LSP). He proposed using LNURLs to asynchronously generate invoices. These invoices could carry a tag to alert the sender that the receiver is connected to an LSP but is currently offline. The sender would then send a payment instruction with a long timeout to their LSP, requesting it to withhold the payment until a certain message is received.
The LSP receiving the payment does not immediately forward the payment, leaving only the sender's own funds "locked" for the unfinished payment. The sender then instructs the recipient's LSP to send a message to their own LSP when the recipient comes back online. The sender can then safely log off. When the recipient comes back online, their LSP sends a message to the payer's LSP, triggering the forwarding of the payment.
This strategy eliminates the need for third-party custodianship at any time. This means funds cannot be stolen; technically, LSPs cannot be defined as custodians for regulatory purposes. Furthermore, once the BOLT 12 specification is finalized, it could replace LNURL. This would make asynchronous payments less dependent on external servers (which LNURL does).
The problem with the LNURL approach is that users still need to trust a third party to provide invoices. There's no guarantee these service providers won't reuse invoices, allowing the LSP to steal funds. One way to improve this is to use PTLCs . This would require the sender and the LNURL service provider to collude in order to steal funds, but there's no reason for the sender to do so.
While no solution to trust relationships is perfect, these are better approaches than the simple approach above. Matt's suggestion relies on trusting the LNURL provider, and the payment is already overdue, just like the simple approach.
in conclusion
In the race to make Bitcoin payments faster and more efficient, the Lightning Network has emerged as a leader. However, despite its potential, the synchronous nature of Lightning payments currently highlights gaps in user experience.
Traditional Bitcoin payments are simple and flexible, as the sender and receiver don't need to be online at the same time. Lightning payments, on the other hand, require both parties to be online at the same time, creating a potential barrier to use.
Crude solutions, such as relying on third-party invoice custodians and node-deferred forwarding strategies, introduce trust into a system striving for trustlessness. Matt Corallo's 2021 proposal, leveraging LNURL and Lightning Network providers, offers a promising foundation. It minimizes locked liquidity, eliminates third-party custodians, and promises compatibility with the upcoming BOLT12 specification. However, trust issues associated with LNURL remain a concern. Innovations like PTLCs would add additional security.
The adventure of implementing asynchronous payments in the Lightning Network has begun, and various proposed solutions are bringing us closer to a seamless and trustless payment experience.
(over)
