LibraryInteroperability2013Design paperCorpus record
Bitcoin Payment Channels
Payment channels. Mike Hearn and Jeremy Spilman.
Two parties lock coins in a shared output and exchange updated transactions that are not broadcast. Only the last state, or a dispute, hits the chain.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
A payments pitch that never names the dispute timeout has skipped the only reason the chain is still involved.
The five-minute read
The defect
Putting every coffee on the Bitcoin chain makes the chain the bottleneck and the fee schedule the product.
The rule
Two parties lock coins in a shared output and exchange updated transactions that are not broadcast. Only the last state, or a dispute, hits the chain.
How it is put together
The lock is on-chain. The updates are off-chain. A dispute needs a timeout so an old state can be punished or replaced. Capacity is the locked amount, not the chain's throughput.
Where the claim stops
This early design is not the Lightning protocol.
One action, walked through
- Open by funding a shared output.
- Exchange signed updates that spend it.
- Close by broadcasting the latest, or dispute if the other party broadcasts an old one.
- What is broadcast if both parties vanish?
The argument, unpacked
Why it is still on the desk
A payments pitch that never names the dispute timeout has skipped the only reason the chain is still involved.
After the text
Lightning is the routed version of this idea, with its own penalty rules. The 2013 sketch is the bilateral case.
What has to be true
- This early design is not the Lightning protocol.
- A channel that cannot punish an old state is a different, weaker object.
- Capacity is not the same as a bank balance.
What happened after the paper
Lightning is the routed version of this idea, with its own penalty rules. The 2013 sketch is the bilateral case.
What to check before you use the idea
- What is broadcast if both parties vanish?
- How long can an old state be contested?
- Who holds the keys to the locked output?
Terms
- Channel
- A locked output whose balance is updated off-chain.
- Dispute
- The on-chain path that rejects a stale update.
The problem the paper names
Putting every coffee on the Bitcoin chain makes the chain the bottleneck and the fee schedule the product.
What the design proposes
- The lock is on-chain. The updates are off-chain.
- A dispute needs a timeout so an old state can be punished or replaced.
- Capacity is the locked amount, not the chain's throughput.
How the mechanism is specified
- Open by funding a shared output.
- Exchange signed updates that spend it.
- Close by broadcasting the latest, or dispute if the other party broadcasts an old one.
What this page does not treat as proven
- This early design is not the Lightning protocol.
- A channel that cannot punish an old state is a different, weaker object.
- Capacity is not the same as a bank balance.
Why a venture studio still reads it
A payments pitch that never names the dispute timeout has skipped the only reason the chain is still involved.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.