Visualizing HTLCs and the Lightning Network’s Dirty Little Secret

A Lightning channel can be thought of as a string of beads stretched between two people. Referring to Fig. 1, Alice can pay Bob by pushing one of her beads to his side. If Bob also has a Lightning channel with Carol, Alice can pay Carol through Bob: she pushes a bead over to Bob, who then pushes a bead over to Carol. The fundamental rule — and the reason behind the Lightning Network’s liquidity problems — is that the beads can move from side to side but cannot leave the string they’re on.

Fig. 1. Alice can send a payment to Carol by routing it through Bob. Because beads cannot leave the string they are on, Bob ends up with one more bead on his string with Alice, and one fewer bead on his string with Carol.

That’s all you need to know to understand the way money can flow in the Lightning Network. But this model doesn’t tell us anything about why Lightning payments are secure. For example, what is stopping Bob from simply keeping the bead Alice pushed towards him and never sending one on to Carol? The purpose of this article is to answer the question “what makes Lightning payments ‘trustless’?”

At the end of the article, we’ll reveal the Lightning Network’s dirty little secret: that small payments aren’t actually “trustless” at all— routing nodes can lose customer funds.

Hash- & Time-Lock Contracts (HTLCs)

To explain what prevents Bob from keeping the bead from Alice without sending one on to Carol, we need to introduce “locks” to our physical analogy for Lightning channels. Locks can be placed on the strings to constrain the movement of the beads, and only opened if specific conditions are met. The hash- and time-lock contracts (HTLCs) used in Lightning payments involve two types of locks (cf. Fig. 2): the first is a lock that opens if presented with the correct password (we’ll call this a “hash-lock”), and the second is a lock that opens automatically after a time delay (we’ll call this a “time-lock”).

Fig. 2. The hash-lock opens when a password is entered that hashes to the specified value (45f8 in this case). The time-lock opens after the specified time has elapsed (48 hours in this case).

Let’s now return to the payment of one bead from Alice to Carol through Bob. To make the payment “trustless,” Alice, Bob, and Carol need to be online at the same time and participate in an elaborate ritual.

First, Alice asks Carol to think up a secret password and tell her the password’s hash. Let’s pretend the password Carol thought up was “boondoggle” and its hash was “45f8.” Next, Alice places a hash-lock between her and Bob, set to open when presented with a password that hashes to “45f8.” At this point in time, neither Alice nor Bob can open the lock because neither know the password. Alice then pushes a bead against the hash-lock. Lastly, she places a time-lock on the left side of the bead, set to automatically open after 48 hours (Fig. 3).

Fig. 3. With knowledge of the hash of Carol’s secret password, Alice can set a hash-lock to protect the coin she shifts to Bob (to then route to Carol). She locks the coin in with a time lock so that she can get it back should Bob fail to complete the payment within 48 hours.

Bob sees that the bead is his if he can figure out the password before 48 hours is up. He also knows (because Alice told him) that Carol will reveal the password in exchange for one of his beads. To entice Carol into action, Bob places the same hash-lock between himself and Carol, pushes over one of his beads, and then locks it in with another time-lock (Fig. 4). He knows that in order for Carol to open the hash-lock and take the bead, she’ll need to enter the password — in plain sight — which is the same password Bob needs to open the hash-lock with Alice.

Fig. 4. Bob sees that the coin from Alice is his if Carol will reveal her password before 48 hours is up. He sets the same hash-lock, pushes a coin towards Carol, and locks it in with a time-lock. The only way Carol can take the coin from Bob is to reveal the password that Bob needs to claim the coin from Alice.

Carol, upon seeing that the bead is hers for the taking, enters “boondoggle” into the lock (in Bob’s plain sight remember). The lock’s CPU confirms that `hash(“boondoggle”) = 45f8`, and then opens. Carol moves the bead to her side of the string (Fig. 5).

Fig. 5. Carol reveals her password to open the lock and take the coin.

With knowledge of Carol’s password, Bob unlocks his bead from Alice in the same way (Fig. 6). The payment is complete.

Fig. 6. With knowledge of Carol’s secret password, Bob can now take the coin from Alice, thereby completing the payment.

You might wonder why Bob would bother to participate in this ritual in the first place. Had Carol not been cooperative, his bead may have been frozen until the time-lock expired. In practice, Alice would send Bob a little more than what she asks Bob to send to Carol, as a fee to compensate for this risk and for Bob’s effort. When the payment is complete, Bob would have a bit more than he started with, thereby motivating him to complete the payment.

You might also wonder what purpose the time-locks serve. The time-locks allow the participants to recover their funds if the payment fails. For example, imagine that Bob becomes uncooperative after Alice shifts her bead over and adds the two locks. The time-lock is what allows Alice to get her funds back. She just needs to wait for the time-lock to expire. There’s no way for Bob to steal the bead in the meantime, because he needs the password from Carol, which he can’t get without giving Carol one of his beads and thus completing the payment.

Interested readers can explore what happens if one party becomes uncooperative at different steps in the Lightning payment process to convince themselves that neither Alice, Bob, nor Carol are at risk of losing money due to the action of their counter-parties.

The Lightning Network’s Dirty Little Secret

The Lightning Network has a dirty little secret few people know. To understand what the secret is — and its ramifications for Lightning payments — we need to dig a bit deeper.

Recall that when Alice sent the payment to Carol through Bob, the intermediate state shown in Fig. 7 existed. When expressed as a bitcoin transaction, the channel state contains three outputs: Alice’s coins, Bob’s coins, and the coin “in flight.”

Fig. 7. The Lightning channel state transaction at this point in time contains three outputs: Alice’s coins, Bob’s coins, and the coins in-flight.

Here’s the problem: if the value-in-flight is below the BTC dust threshold, then it cannot be represented as a third output in the channel-state transaction! It is thus not possible to use hash- and time-locks to protect the payment if the payment is too small.

To explain how the LN deals with this problem, I must first make a confession. It is not exactly true that the number of beads on a string is constant. There is actually a bucket beside each string labelled “Miner’s Fee” that contains small fractions of beads. The value in this bucket gets claimed by the miner who confirms the channel-state transaction, should the channel state be pushed to the blockchain. Fractions of beads can move from the string to the bucket, or from the bucket back to the string, but only if the persons on both sides of the channel agree.

Rather than locking the value in-flight with hash- and time-locks, for small payments Alice and Bob just move the value-in-flight into the fee bucket (Fig. 8). Bob trusts that Alice will cooperate with him to take the value-in-flight out of the fee bucket when he reveals Carol’s secret password.

Fig. 8. If the coins in-flight are below the dust threshold, the HTLC mechanism cannot be used because the channel-state transaction would not get mined if broadcast. Instead of using the HTLC mechanism, the coins-in-flight are dumped into the “Miner’s Fee” bucket.

Bob then dumps the value-in-flight into a second fee bucket he shares with Carol, promising to give it to her if she tells Bob the secret password. Carol tells Bob the secret, and Bob and Carol together move the payment from the fee bucket to Carol’s side. Bob then goes back to Alice, tells her Carol’s secret, and, if all goes well, Alice cooperates with him to take the value-in-flight out of the fee bucket and place it on Bob’s side of the string.

Unlike the HTLC scheme described earlier, this scheme relies on trust. For example, Carol could reveal the password to Bob, who could then leave the payment in the fee bucket yet still go to Alice and deliver the password in exchange for his payment.

Carol’s recourse in this scenario is limited: she either does nothing and accepts the loss, or she closes her channel with Bob. But closing her channel with Bob doesn’t make her whole, because the value she should have received gets sent to a miner instead!

Despite how broken the above scheme sounds, it actually works reasonably well in practice. Bob has no real incentive not to give the money to Carol. If he doesn’t give it back, he’ll be no better off (the miner will keep the extra funds, not him) and probably worse off (Carol will likely close the channel since Bob has proven himself untrustworthy). The damage Bob can do appears limited to the value of the payment plus the cost of establishing a new lightning channel.

Why this is significant

Lightning’s dirty little secret is significant because it reveals how friction from Layer 1 (L1) leaks into L2, forcing complex and poorly-understood¹ work-arounds to the L2 protocol. The work-around in this case changed the “trustless” nature of Lightning payments: for payments above the dust threshold, neither Alice, Bob nor Carol can lose money due to the actions of their counter parties. For payments below the dust threshold, Alice, Bob and Carol can lose money through no fault of their own. It is a fundamentally different security model from what people understood.

One might argue, “we’re just talking about tiny payments so who cares.” I don’t buy this argument for two reasons:

• Core’s scaling plan of using the blockchain as a high-fee settlement layer will increase the threshold for what constitutes “dust.” Dust are outputs that cannot be economically spent because the on-chain fee to spend them is greater than their value. With $100 fees, most of the world’s entire monthly wage is “dust.”
• Losing several tiny payments in quick succession (e.g., due to a LN routing attack) could result in a significant loss.

Imagine a future where the majority of payments take place on the Lightning Network, and transaction fees on L1 are consistently over $100. Dust outputs below $100 on the main chain have no value because it costs more to spend them than they’re worth.

Now the Lightning Network has the problem where even $50 payments are not “trustless.” In the case where $50 is below the dust threshold (which would be reasonable policy considering that $50 would be economically unspendable on L1), then HTLCs cannot be used to protect the $50 payment. Customers can lose $50 payments through no fault of their own.

In the case where developers try to get around some legal “loop hole” by setting the dust limit to $1 so that HTLCs can still be used, the effect is still a $50 loss to the customer because the output will not be economically spendable! Customers can still lose $50 payments through no fault of their own.

One might argue “well OK routing nodes can lose customer funds and those funds might be significant in a high-fee future, but routing nodes are peers not businesses.” I don’t buy this either because the entire purpose of routing Lightning payments is to earn money in transaction fees in exchange for lending liquidity. Already today, the Lightning developers have abandoned the idea that all users would route payments; now it is encouraged that normal users use non-advertised channels and never route.

In a high-fee future a hub has effectively custodial control over its users’ money. A user cannot settle on the blockchain to recoup funds for payments not protected by HTLCs . Further, if the user’s balance is on the same order of magnitude as the on-chain fees, the user is also trapped by the hub. It is simply not worth escaping from a “bad” channel because doing so would cost the user their entire balance. Hubs can thus also lock customer funds indefinitely by refusing to route payments unless certain conditions are met (e.g., unwrapping the onion-routing information for AML/KYC purposes). The user’s only choice is to settle on the blockchain and lose all their money — which isn’t a real choice at all! Hubs can also steal from their users in the form of exorbitant fees. Again, the user is trapped and has no choice but to pay if they want access to their money.

Well-connected Lightning hubs in a future with high on-chain fees should be regulated as they have effectively custodial control of their customers’ funds.

I’d like to hypothesize that the following law exists:

Payments on Layer 2 for amounts below what is economically feasible to carry-out on Layer 1 cannot be made “trustless.”

Lightning will only work as people expect if the underlying blockchain is unconstrained.

More

This is just one of many reasons why a future where most transactions take place on the Lightning Network and the blockchain has high fees will be very different than people expect. Other reasons include:

• Lightning scales transactions, not users. The cost to run a full validating node will still be high.
• Friction on L1 affects fungibility on L2; coins have position-dependent value.
• Liquidity: most “wealth states” are not reachable via Lightning transactions. Payment failures are unavoidable.
• Routing is hard if the network graph is large: Lightning hubs will centralize to reduce routing and liquidity problems.
• The typical user-experience of running a non-custodial wallet will always suck: users need to be online to receive money, hire watchtowers to monitor for channel fraud, subscribe to source-routing services to send payments, and dynamically back up their channel states against data corruption.
• Systemic risk: a very large amount of coins need to be locked in Lightning channels (hot wallets) to provide the needed liquidity.
• Aggregate miner fees on L1 will not be sufficient to secure the blockchain when the block reward runs out.

Footnotes

¹ For example, I have been called a liar and received harsh feedback on Twitter and Reddit (even by people working on LN) for pointing out that LN is not “trustless” for small payments and that customer funds could be re-routed to the miners through no fault of the customer. The widely-held-but-false belief within the BTC community was the all Lightning payments were “trustless” by design.