The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments

The five-minute read

One action, walked through

1. Two parties fund a multisig output on Bitcoin. That funding transaction is the channel's only required public opening.
2. They exchange signed commitment transactions that spend the funding output to a new split. Each new commitment revokes the old one.
3. To pay across the network, the sender finds a path and uses hash-locked or point-locked contracts so each hop can claim only by revealing a secret the recipient knows.
4. Each hop updates its own channel. No hop needs to put the payment on Bitcoin.
5. If a party disappears or cheats, the counterparty broadcasts the latest commitment, or a penalty transaction, and waits out the timelock the contract specifies.

The argument, unpacked

What has to be true

• Both parties, or a watchtower, can get a penalty transaction confirmed in time.
• Hash preimages or adaptor secrets are revealed only when the previous hop is ready, so a hop cannot claim without passing the payment on.
• Channel counterparties are chosen with some care. A channel with an offline peer is frozen capital.
• The Bitcoin scripts used match what the paper's update rules expect. A soft-fork changes what is possible.

What happened after the paper

Lightning deployed with evolving channel types, anchor outputs, and point-timelock contracts replacing the original hash-timelock path in much of the network. Watchtowers exist and are not universally used. The 2016 paper is the channel-and-route argument. Capacity and uptime are properties of today's graph.

What to check before you use the idea

• Who watches for an old-state broadcast, and what is the timelock?
• Does a payment of this size have a path with enough balance, or only a theoretical route?
• What happens to a channel if the counterparty is offline for a month?
• Which script version is live, HTLC or PTLC, and does the citation match it?

Terms

Channel

A funded output plus a series of signed balance updates that are not broadcast until settlement or dispute.

Revocation

The step that makes an old balance dangerous to publish, because the counterparty can then claim a penalty.

HTLC

A conditional payment that completes only if a hash preimage is revealed in time.

Watchtower

A service that watches the chain for a cheat and broadcasts the penalty if the user is offline.

The problem the paper names

Every Bitcoin payment that lands on the chain competes for the same block space. The paper's claim is that two parties who pre-commit funds on-chain can update a balance many times off-chain, and only settle on-chain if they disagree or finish.

What the design proposes

• A channel is a multisignature output plus a stack of commitment transactions, of which only the latest should be broadcastable.
• Revocation keys penalise a party who publishes an old state.
• HTLCs let a payment cross several channels if the same hash preimage unlocks each hop.

How the mechanism is specified

• The chain is the court, not the cash register. It is used to open, to dispute and to close.
• Routing is source-routed in the paper's presentation. Pathfinding, liquidity and fees are economic problems on top of the construction.
• Time locks are the safety tool and the griefing surface. Both belong in a reading of the paper.

What this page does not treat as proven

• The paper is about Bitcoin's scripting as it was specified. It is not a generic 'layer 2' for every chain.
• It does not prove that a route with liquidity will exist when a user wants to pay.
• Later BOLT specifications are the implementation standard. This PDF is the design argument.

Why a venture studio still reads it

A payments venture that says 'we'll settle on a base chain' should be able to say whether the user payment is the settlement or whether the settlement is only the dispute. Lightning is the document that makes that split precise.