Blogs & Articles: The Past, Present, and Future of Offline Payments 🔗 14 weeks ago

Nobody is more critical of Lightning than its most passionate proponents. Guys like me. Guys like Ben Carman. In a recent Stacker News post, he highlights liquidity and offline payments as aspects of Lightning that impede the UX and deter self-custody. This might seem like just another complaint about how the future isn’t living up to its promise. We were promised flying cars, and all we got was the miracle of the internet. Everything is amazing and nobody is happy.

On closer inspection, though, Ben’s got a point. I’ve been talking about the Lightning UX for years, including the challenge of offline payments. We even proposed a solution to the offline payment problem back in 2019 (I’ll explain below why we never implemented it).

It might feel as if the promised future is perpetually out of reach, but building Lightning is a lot like climbing a mountain. Climbers never really see the summit until they’re standing on top of it. They often can’t even see over the next ridge. Planning the ascent is important, but most of the time you’re simply concentrating on the next foothold. But the steps add up. Just like the view from the top is the reward for all that effort, a brighter monetary future will be our reward for building the network bit by bit. That’s how Lightning has progressed from an idea to a functioning bitcoin payment network, and it’s how we’ll reach our destination.

And like mountain climbing, none of us will get there alone. (Image: Sylvain Mauroux)

Since offline payments are a longstanding UX challenge, let me review where this problem comes from, what tech is currently available to deal with it, and what’s on the horizon. (I’ll review Ben’s other beef — channel liquidity — in a coming post.)

The Problem

People who’ve only ever experienced fiat, on-chain bitcoin, or custodial wallets might not even be aware that “offline payments” are a thing. Fiat and custodial wallets solve the problem by taking control of users’ money. The bank/custodian receives funds/IOUs from other users’ banks/custodians and sends the funds/IOUs when users ask them to. If the user never actually has custody of the funds, it doesn’t matter whether they’re online or not. Only those who actually control the money need to be online. With on-chain bitcoin, a sender needs only the recipient’s address.

Self-custodial Lightning is more challenging because both parties to a transaction need to be online simultaneously. The recipient needs to send an invoice to the sender, the sender needs to initiate the payment, and the recipient has to sign it. This arrangement restores users’ control over their own money, but it can also be a pain in the UX.

The Past: Trials and Errors

There were 11 recorded attempts to climb Everest before Norgay and Hillary finally succeeded. Breez’s first attempt to crack offline payments was called “Connect to Pay,” which prompted the sender to notify the recipient when a payment was about to go through so the recipient would open their Lightning app. The underlying UX idea was analogous to a phone call: just get both parties occupied with the same thing simultaneously. But the ability to receive payments without conscious effort is simply too ingrained. It’s the UX we all expect, and nothing less will do. (People don’t even like phone calls. They sing songs about it.)

Our next idea, which we called Lightning Rod, was more sophisticated. The idea was to use HODL invoices to let a routing node between the sender and the recipient intercept the payment until the receiver became available. Therefore, it was a lot like Zeus’s Zaplocker idea.

Although Lightning Rod works, we never put it into production because HODL invoices don’t scale for routing nodes. They tie up funds. When a routing node holds a transaction, it’s basically extending an interest-free loan to the recipient. Liquidity must flow. Solving the problem of async payments by freezing them en route just aggravates the liquidity problem.

We were on the right mountain, but taking the wrong lines up.

The Present: Existing Means to Support Offline Payments

The good news is that technologies have evolved to deal with offline payments. No existing approach is a perfect solution in that they all have trade offs, but each is useful in different ways.

LNURL-Withdraw

The first is LNURL-Withdraw. Recipients can scan a QR code or enter a URL that instructs their app to request funds from a sender. For example, a user who wants to withdraw funds from an exchange can “pull” their funds at their convenience instead of the exchange pushing while they are offline.

There are two major drawbacks with this approach. First, it requires the sender to have a node running on a server that’s perpetually online, so it’s inappropriate for non-custodial mobile or web clients. Second, the “pull” model only applies to very specific use cases when users know they have funds to redeem. For example, it would be hard to spontaneously tip someone.

The Breez SDK Approach: Leverage Mobile Notifications

Mobile notifications are another means to support offline payments. Triggering a mobile notification in iOS or Android can even give the client app enough time on the CPU to receive the payment. Using mobile notifications to process incoming payments doesn’t require active involvement from the recipient and provides a natural, non-intrusive solution to the simultaneity problem. That’s why we’ve included a new feature in the Breez SDK to facilitate offline payments using push notifications. It’s a major UX improvement for SDK users requiring just a little work from developers.

The Breez SDK approach works like this: first, the devs create a webhook that an LSP can call when a payment is en route. As soon as the payment hits the LSP as the last hop before the recipient, the LSP calls a Notification Delivery Service (NDS) via webhook, and the NDS sends a push notification to the user’s phone with instructions. It requires a little legwork on the developers’ part in the form of setting up an NDS, but the result is a much better UX because users don’t need to keep the app in the foreground to receive payments. It also enables mobile users to receive payments using a static address (e.g. Lightning address, LNURL-Pay or BOLT12).

Mobile notifications are an improvement, but not a cure-all. They only work on mobile devices, obviously, and this approach won’t work if the device is off or the user has disabled the notifications required. Moreover, Google or Apple could negate its effectiveness by changing how their operating systems handle notifications. That’s why we need a solution built into the Lightning protocol.

The Future: Building Async Payments into Lightning

The idea behind the next phase of offline payments is simple: make payments asynchronous. Since the simultaneity problem affects self-custodied mobile and web users most acutely, and practically all such users connect to Lightning through LSPs, why not leverage their always-online LSPs to synchronize the payment when the sender or receiver are offline?

LSPs can decompose the payment flow in time by intercepting HTLCs, which eliminates the simultaneity problem or, rather, shifts it to the level of LSPs, for whom it is no problem. It all starts with a message embedded in the invoice indicating that the recipient is offline but connected to an LSP. The sender sends the payment with a message to their own LSP to hold it with a long expiry time pending further instructions. The sender then messages the recipient’s LSP asking it to alert their own LSP (who is still holding the payment) when the recipient is back online. At this point, it’s basically up to the LSPs. When the recipient comes back online, their LSP signals the sender’s LSP to forward the payment.

This model doesn’t compromise the overall liquidity of the network because the only node where the funds can be frozen is the sender’s own LSP, which is what the user actually wants.

As simple as it sounds, this approach requires more tech to work optimally: static invoices, onion messages, blinded routes, trampoline payments and eventually PTLC. It’s complicated, but those who want to dig deeper can watch my Honeybadger 2023 session. While some Lightning implementations already support some of these features, it will take some time before the entire network adopts them, which is crucial for interoperability.

When Will the Future Arrive?

Of course the sun will rise tomorrow, but it’s already shining today. My point is that we already have different, functional ways of handling offline payments on Lightning without relinquishing custody, each suited to a different use case. LNURL-Withdraw already works for some commercial contexts, and the new Breez SDK feature enables offline payments for mobile devices.

That’s cool! We didn’t always have that, but now we do. We’re already living in yesterday’s future.

A protocol-based solution remains a work in progress. Many implementations like Eclair, LDK, lndk and Core Lightning (yes, I’m looking at you lnd) are making progress on the features required to make it happen. When implemented, async payments will represent a huge UX improvement. It’s a future worth pursuing.

When we get there, I’m sure there will be other challenges on the horizon demanding our attention and testing our patience, but let’s never forget how high we’ve climbed already.

The Past, Present, and Future of Offline Payments was originally published in Breez Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.