Introduction

The Lightning Network emerged as a scaling solution for Bitcoin payments. However, as we dive deeper into the nuances of Lightning, we uncover areas that still need enhancements. One notable aspect is the concept of asynchronous (async) payments – a feature that, if delivered, could significantly improve the payment process and user experience.

Traditional on-chain Bitcoin payments operate with a simplicity derived from its asynchronous capabilities. To elucidate, let’s go through an example: let’s pretend that Alice wants to pay Bob for guitar classes. Alice goes to Bob’s social media profile, where he has a Bitcoin address in his bio. To send the payment to Bob, Alice must copy the address, paste it on her Bitcoin wallet, and hit send. The transaction will be queued up and subsequently confirmed on Bitcoin’s blockchain. When Bob opens his wallet, he’ll see the new deposit from Alice.

However, if Alice wanted to pay Bob over the Lightning Network, the user experience wouldn’t be the same. To pay someone over Lightning, both sender and receiver must be online and exchange information. With its inherent challenges, this difference paves the way for our exploration into the nuances of async payments within the Lightning Network.

A Brief Overview of Lightning Payments

To grasp the concept of async payments, it’s beneficial first to understand how payments work at the moment.

On the Lightning Network, if Alice wants to send money to Bob, she must first request an invoice from him. This means Bob must actively access his Lightning wallet to generate a new invoice for Alice’s transaction. Unlike traditional Bitcoin transactions, Lightning Network invoices are one-time. Paying an invoice more than once opens the possibility of losing funds for the sender.

After getting Bob’s invoice, Alice uses her Lightning wallet to send the payment. Internally, her payment travels through a series of Lightning channels until it reaches Bob. Upon receiving the payment, Bob’s node sends a confirmation back. This confirmation ensures that each intermediary node gets its fees and confirms to Alice that the payment was successful. If Bob’s node is offline, the payment won’t be completed. While the Lightning protocol ensures no money is lost, it poses a user experience challenge since maintaining a continuous online status, especially on mobile devices, is impractical.

In summary, Lightning Payments face two main synchronization hurdles:

• Receivers need to create a unique invoice for every payment actively.
• The receiver’s node has to be online at the time of payment, or the transaction will not go through.

Handling Async Payments

What is an async payment on Lightning?

Asynchronous payments within the Lightning Network refer to transactions initiated even when the recipient is offline. An intermediary node securely holds these payments and are only completed once the recipient reconnects to the network.

Naive approaches

At first glance, making Lightning payments asynchronous can seem easy. The invoice interactivity issue could be solved by having Bob’s node generate many invoices and hand them to a third-party server that sends the invoice at someone’s request. The confirmation issue could be solved by making the last node in the payment route hold the payment until it sees Bob’s node online.

Unfortunately, these approaches have a lot of issues. The most obvious one is that they introduce trust into a payment system that was designed to be trustless. The receiver has to trust the invoice “holder” to provide an honest service, and he also needs to trust that the last node in the route will send him the payment once he becomes online. Another issue is that invoices and Lightning payments expire. Lastly, all the nodes in the payment route will have that liquidity locked until either Bob comes online or the payment expires. This is bad because routing nodes want to be effective with their liquidity and having the liquidity locked for an uncertain amount of time is ineffective.

Can we do better?

Back in 2021, Matt Corallo suggested a compromise that can improve async payments. It requires the use of LNURL and that both sender and receiver be connected to Lightning Service Providers (LSP). He suggests using LNURL for the asynchronous generation of invoices. The invoices can have a flag to signal the sender that the receiver is connected to a Lightning Service Provider (LSP), but rarely online. Then, the sender sends the payment with a big expiry with instructions for the LSP to hold the payment until it receives a message from it.

The LSP accepts the payment but does not forward it. This way, the only funds “locked” while the payment is not completed are the sender funds. Then the sender asks the receiver’s LSP to message the sender’s LSP once the receiver is back online. From here on now, the sender can safely go offline. When the recipient comes online, their LSP sends the message to the receiver’s LSP, causing it to forward the original payment.

Using this strategy, there are no third-party custody funds at any given point. This means that funds cannot be stolen, and technically, the LSPs can’t be classified as custodians in a regulatory sense. Furthermore, once the BOLT 12 specification is completed, it might substitute for LNURL. This would make async payment less reliant on external servers, as with LNURL.

The issue with LNURL is that the user still has to trust the third party providing the invoices. There’s no guarantee that the service provider will not reuse invoices, allowing the LSPs to steal money. One way this can be improved is by using PTLCs. This way, the sender and the LNURL service provider have to conspire to steal the money. But there’s no sense in the sender doing this.

Although not a perfect solution regarding trust, it’s a better way to handle the issue than the naive approach described earlier. Matt’s suggestion relies on trust in the LNURL server and payments can still expire, as was the case in the naive approach.

Concluding

In the quest to make Bitcoin payments faster and more efficient, the Lightning Network (LN) has presented itself as a promising solution. Yet, despite its potential, the current synchronous nature of Lightning payments highlights a user experience gap.

Traditional Bitcoin payments offer simplicity and flexibility, allowing for transactions without both parties being online simultaneously. In contrast, Lightning payments require this synchronicity, creating potential user obstacles.

Initial solutions, like relying on third-party invoice holders or node-holding strategies, introduce elements of trust into a system designed to be trustless. Matt Corallo’s 2021 suggestion, leveraging LNURL and Lightning Service Providers, offers a promising middle ground. It minimizes locked liquidity, sidesteps third-party custody, and potentially integrates with the upcoming BOLT 12 specification. However, trust issues with LNURL remain a concern. Innovations like PTLCs might provide added security.

The journey towards fully asynchronous payments on the Lightning Network is in progress, with each proposed solution bringing us closer to a seamless and trustless payment experience.