Introducing Lightning Rod
Asynchronous Lightning Payments for an On-Demand Culture
Video on-demand, which allows viewers to watch broadcasts asynchronously, is now over 25 years old. Telephone answering machines (i.e. strictly hardware-based voicemail), which allow for asynchronous conversations over great distances, are over 80 years old. The cheque, which allows for asynchronous payments with the payer and the payee in different places at different times, might even be 2300 years old.
On-demand has been the way of the future for a very long time. It’s increasingly becoming the present. And the UX is constantly improving. We don’t even record TV anymore; we stream it. We don’t leave voice messages; we use a messenger app. We don’t write cheques; we’ll send a Venmo. We expect products and services to be available when we are.
Lightning needs to catch up.
Conventional Lightning payments redux
First, let’s recap how conventional Lightning payments work. (If you’re already familiar with the protocol, go ahead and skip to the next section. If you want even greater detail, see here or here and come back when you feel a deep, personal connection with Alice, Bob, and Carol.)
Step 1:
In a conventional Lightning payment, Carol (i.e. the payee) starts the process by invoicing Alice (i.e. the payer). Carol’s invoice contains a hash of a preimage she created.
Step 2:
Alice sends Bob (i.e. a routing node) an HTLC payment locked with the hash of Carol’s preimage.
Step 3:
Bob sends an HTLC payment to Carol, which she can open with the preimage whose hash she originally sent.
Step 4:
Once Carol has received the HTLC payment from Bob, she can share the preimage with him too, which allows him to unlock Alice’s HTLC. Once he receives the preimage from Carol, he forwards the preimage to Alice and completes the HTLC payment cycle.
Step 5:
Once Alice receives the preimage from Bob, the final step is to reiterate the process by replacing the HTLC transactions with commitment transactions, which allow the payment channels to remain open.
The problem: simultaneity
Custodial wallets have it easy. They simply separate users from their money and manage everything remotely on their server — as if bitcoins were no more than Candy Crush tokens.
Non-custodial clients take their users seriously, leaving the users in control of their own money, but this comes at a UX cost. For a conventional Lightning payment to be completed over a non-custodial client, both parties — the payer and the payee — have to have their clients open at the same time. Unless both of them have their mobile apps running in the foreground simultaneously, neither can initiate a payment.
The two parties can be in two different places, but they have to be available for each other at the same time — just like a phone call. In the on-demand age, requiring users to wait on a service or each other is retrograde. Fiat does asynchronous payments better, and surpassing fiat is what we’re here for.
Our current workaround for the problem of getting the clients at either end of a payment online simultaneously is what we call “Connect-to-Pay.” It allows one party to message the other with a link that, when the second user clicks on it, will open the payment session at her end. Sure, it’s better than a QR code, but it’s still not optimal. Connect-to-Pay is about as convenient as a phone call — it overcomes spatial distance, but not the simultaneity requirement. And who prefers a call over a text for a quick notification?
Now with a text, you can convey the same information, it’s available at the recipient’s convenience, and it’s sent over a single medium without the simultaneity requirement of a call. That’s where we’re going.
Lightning Rod — the new standard
Lightning Rod enables users to complete payments asynchronously. In other words, they react when they want, not when the client wants them to. We’ll provide a simplified depiction of how it works here, but you’re welcome to check out our GitHub for full details.
How Lightning Rod works
With Lightning Rod, the payer (Alice) starts the process. And there is no Bob. In his place, there is a node running a protocol. Let’s call the node “Rod.”
Step 1:
Alice sends a secret to Carol. And then she can go offline and enjoy her life.
Step 2:
Carol generates a preimage and sends a hash of Alice’s secret and a hash of the preimage (i.e. a payment invoice) to Rod. This effectively splits the Alice → Carol payment into two payments: Alice → Rod and Rod → Carol.
Carol can now go offline and enjoy her life too.
Step 3:
Rod sends Alice a hash of the secret along with a HODL invoice containing the hash of the preimage he received from Carol. (Briefly, a HODL invoice allows the recipient to defer or cancel the payment beyond the limits of the HTLCs, but the sender remains committed.)
Using the hash of the secret, Alice can validate the payment source, meaning that Alice can validate the payment request that Carol initiated. And thanks to the HODL invoice, there’s no immediate settlement with Rod.
Step 4:
Once Alice has validated the payment, she sends an HTLC to Rod, who then sends an HTLC to Carol, and the process continues from Step 2 of the conventional procedure above.
In other words, once the payer initiates the process, the payee can send the invoice at her leisure, and the payer can pay it when she pleases. Rod ends up doing most of the waiting, but that’s okay. This old heart will wait for you.
There are a few crucial features to note.
- Unlike a conventional Lightning payment, there is direct Alice → Carol communication in the first step when Alice sends the initial secret. She can send this secret through the secure messaging app of her choice.
- The transaction remains trustless. The initial secret only serves to prove Rod’s credentials to Alice (i.e. “Don’t worry. Carol sent me.”). But Rod cannot use Alice’s funds without Carol’s preimage.
- Although there are two separate invoices, the single preimage effectively binds them together in a single payment procedure.
- Whenever the payer and the payee are using the same Lightning Rod, it will know the source, destination and the amount of the transaction. Users can enhance their privacy by using multiple, randomly selected Lightning Rods, which is similar to using trampoline routing nodes. The protocol supports using multiple Lightning Rods for the same payment, such that Carol would send the information to Rod B, and Rod B interacts with Rod A, so Rod A is unaware of Carol (Alice → Rod A → Rod B → Carol).
By the way, I recently explained the process at the Lightning Conference in Berlin. (And if you want to watch my entire presentation, here you go.)
Why?
We’re working hard to promote bitcoin and to topple fiat. That means we have to beat fiat at its own game: be harder than cash and as easy as Venmo. But saying the words isn’t enough. We actually have to innovate — build a better mousetrap and keep improving it.
Lightning Rod is our latest innovation. It brings us all one step closer to achieving the goal of mainstreaming the Lightning economy. It provides the infrastructure for a function we’ve lacked until now — asynchronous payments — and it does so in a way that respects bitcoin’s values and underlying technology.
