How do payments make their way across the Bitcoin Lightning Network?

The Lightning Network is a Layer 2 solution that allows you to create micropayment channels with other Bitcoiners. It allows instant and trustless peer-to-peer transacting while limiting the amount of data needed on-chain. You can read more about how it works in our post here.

Any two individuals on the Lightning Network can transact without needing a direct payment channel open with one-another. The sender does not directly pay the intended recipient; instead, they pay a user with whom they do have a channel open. That user sends a payment to another such user, and so on until the intended recipient receives their payment.

But why are users along the way incentivized to help the sender route the payment, and how does the sender make sure these users can’t steal any of the Bitcoin intended for the recipient? The answer is with Hashed Time Locked Contracts (HTLCs), which I will explore in this post.

HTLCs and Routing Payments

HTLCs are a clever way to trustlessly route payments in the Lightning Network. As the name suggests, they involve hashes, timelocks, and function as a contract between users in the Lightning Network.

Alice, Bob, and Charlie each run a lightning node. Alice has a channel open with Bob, and Bob has a channel open with Charlie. Alice and Charlie do not have a channel open directly with one another.

Alice has a channel open with Bob, who also has one open with Charlie

Alice wants to pay Charlie 1 bitcoin. The first thing Charlie does is create a secret number R that he does not share with anyone.

Charlie places R into a cryptographic hash function and records the output. In short, when you place a number into a hash function, it produces a unique output. The design goal of a hash function is such that if you have the output of a hash function, there’s no way to figure out what the input was.

Charlie takes the output of hashing R, we’ll call this new number H, and sends it to Alice. Note that Alice does not know R — she only knows H, which conceals the value of R.

Charlie sends Alice H, the result of hashing his secret number R.

The Lightning Network is named as such because while Alice and Charlie may not have a payment channel open directly with one-another, a route exists between them in the network of users. Alice sees that a payment route to Charlie exists through Bob, so to pay Charlie, Alice must involve Bob.

Alice sends Bob a transaction for 1.1 bitcoin that Bob can redeem if he finds out R.

Alice sends Bob a signed transaction in their payment channel that would pay him 1.1 bitcoin if he can prove he knows R.

She signs this transaction and sends it to Bob. At a high level, here’s what the new output might look like:

…
OP_IF
  # Make sure the value provided equals H when hashed
  OP_HASH160 H OP_EQUALVERIFY
  OP_CHECKSIG # This branch only works if Bob signs it
OP_ELSE
  # If Bob doesn’t figure out R in X days, Alice can claim this
  # output using her signature alone.
OP_ENDIF

OP_HASH160 H OP_EQUALVERIFY

This part of script:

1. Takes whatever value you provide it

2. Hashes it

3. Pushes H, the concealed secret, onto the stack

4. Compare H with the result of 2.

As you can see, only the secret Charlie knows, R, will make this part of the script work. Bob does not know R, so he has no way of claiming this 1.1 bitcoin for himself right now.

Bob knows that Charlie knows R, and he knows how much Alice promised to pay Charlie. Bob, who has a channel open directly with Charlie, creates the same kind of transaction with Charlie!

Bob sends Charlie a signed transaction in their payment channel that would pay him 1 bitcoin if he proves he knows R.

Once again, the locking script on Bob’s signed transaction might look like:

…
OP_IF
  # Make sure the value provided equals H when hashed
  OP_HASH160 H OP_EQUALVERIFY
  OP_CHECKSIG # This branch only works if CHARLIE signs it
OP_ELSE
  # If Charlie doesn’t claim this in X days, Bob can claim this
  # output using his signature alone.
  …
OP_ENDIF

Instead of being for 1.1 bitcoin, Bob signs a transaction that will give 1 bitcoin of Bob’s own money to Charlie if Charlie knows R.

When Charlie sees that the amount Bob’s transaction would pay him is the amount he expected to receive from Alice, he signs a transaction claiming that output. As we have seen, to claim the output Bob created, you must provide R as an input to your transaction. Because the Bitcoin blockchain is public, when Charlie publishes his transaction claiming the output, he has revealed R to the world!

Bob, seeing Charlie has published a transaction claiming the output he created, finds R from the witness (also called the unlocking script) Charlie used to claim the output. Having R, Bob can now claim the 1.1 Bitcoin from the output Alice created.

What happened here?

In the end, Alice pays Bob 1.1 bitcoin, and Bob pays Charlie 1.0 Bitcoin. The extra .1 bitcoin that Bob keeps is the reason he agrees to help Alice in the first place: he earns a fee in routing the transaction. Whenever someone wants to pay someone else on the Lightning Network, they must account for a small fee that every node collects along the way.

Charlie will only claim the output from Bob if it is for the amount Alice promised him. If Bob sneakily tried to net half of Alice’s bitcoin by sending Charlie a transaction that would only give him .5 bitcoin by revealing R, Charlie would simply not reveal R.

The pursuit of R is why nodes are invested in routing Alice’s payment to her intended recipient successfully. When R is publicly visible on the blockchain, it can mean only one thing: Charlie was paid in full. When that happens, all the users along the way can claim their output entitling them to a small fee.

For simplicity, this example assumes everyone claims their bitcoin by closing their payment channels. In reality, Charlie could reveal R directly to Bob, who could then show Alice he knows R as well. Alice, seeing that Bob knows R (which means Charlie can claim his money at any point), could then send Bob a new transaction for 1.1 bitcoin in their payment channel without any strings attached. Bob could then do the same with Charlie for 1 bitcoin. All three of them can keep their payment channels open this way, and have less clutter on the Bitcoin blockchain whenever they decide to publish the transactions.

Onward & Upward,

Brandon Arvanaghi, Security Engineer