LibraryScaling2016Design paperCorpus record
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
Lightning. Joseph Poon and Thaddeus Dryja.
Poon and Dryja's 2016 design for Bitcoin payments that stay off the main chain inside penalty-backed channels, and that route across a network of those channels using hashed timelock contracts.
Lightning lets two parties lock bitcoin in a channel, update a private balance many times, and publish a transaction on the base chain only when they need to settle or to punish a cheat.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 6
Code
Source, repository, and what is actually hosted
- lightning.network paperhttps://lightning.network/lightning-network-paper.pdf
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
- Conditional payment
- Wallet policy
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
The chain is the court, not the till
Most payments are signed updates to a contract that already sits on Bitcoin. The base chain is used to open, to close, and to enforce.
Claim 02 · Paper model
A channel is a two-person ledger
Each update revokes the previous balance. Both parties hold a signed transaction that pays the current split. Only the latest should be broadcast.
Claim 03 · Paper model
The punishment is the security
If someone broadcasts an old state, the other party has a window to take the funds. The design assumes watchfulness, or a watchtower paid to be watchful.
Claim 04 · Paper model
Routes stitch channels
A payment crosses several channels by a chain of conditional contracts, so intermediaries move value without being given custody of an open invoice.
Claim 05 · Paper model
Liquidity is the practical limit
A channel can only push what it currently holds on that side. Routing fails when the path does not have the balance, even if the cryptography is perfect.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 The chain is the court, not the till
Observation
What the study says
Most payments are signed updates to a contract that already sits on Bitcoin. The base chain is used to open, to close, and to enforce.
Model
What has to hold
The Bitcoin scripts used match what the paper's update rules expect. A soft-fork changes what is possible.
Falsifier
What would retire it
Who watches for an old-state broadcast, and what is the timelock?
02 A channel is a two-person ledger
Observation
What the study says
Each update revokes the previous balance. Both parties hold a signed transaction that pays the current split. Only the latest should be broadcast.
Model
What has to hold
Both parties, or a watchtower, can get a penalty transaction confirmed in time.
Falsifier
What would retire it
Who watches for an old-state broadcast, and what is the timelock?
03 The punishment is the security
Observation
What the study says
If someone broadcasts an old state, the other party has a window to take the funds. The design assumes watchfulness, or a watchtower paid to be watchful.
Model
What has to hold
Both parties, or a watchtower, can get a penalty transaction confirmed in time.
Falsifier
What would retire it
Who watches for an old-state broadcast, and what is the timelock?
04 Routes stitch channels
Observation
What the study says
A payment crosses several channels by a chain of conditional contracts, so intermediaries move value without being given custody of an open invoice.
Model
What has to hold
Hash preimages or adaptor secrets are revealed only when the previous hop is ready, so a hop cannot claim without passing the payment on.
Falsifier
What would retire it
Does a payment of this size have a path with enough balance, or only a theoretical route?
05 Liquidity is the practical limit
Observation
What the study says
A channel can only push what it currently holds on that side. Routing fails when the path does not have the balance, even if the cryptography is perfect.
Model
What has to hold
Channel counterparties are chosen with some care. A channel with an offline peer is frozen capital.
Falsifier
What would retire it
Does a payment of this size have a path with enough balance, or only a theoretical route?
03 Sequence
One action, as an operating tape
- 01Two parties fund a multisig output on Bitcoin. That funding transaction is the channel's only required public opening.
- 02They exchange signed commitment transactions that spend the funding output to a new split. Each new commitment revokes the old one.
- 03To 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.
- 04Each hop updates its own channel. No hop needs to put the payment on Bitcoin.
- 05If a party disappears or cheats, the counterparty broadcasts the latest commitment, or a penalty transaction, and waits out the timelock the contract specifies.
04 Load-bearing
The argument, and where a pitch drops it
Watchfulness is not optional
The cut
The penalty works only if the honest party notices an old state before the timelock expires. A user who goes offline for longer than that window has accepted a different security model. The paper's safety includes this operational duty.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The paper is about Bitcoin's scripting as it was specified. It is not a generic 'layer 2' for every chain.
Routing is a liquidity market
The cut
Intermediaries lock capital in channels and expect to be paid for it. A diagram of six hops does not mean a payment of that size can find a path. Capacity, not signature count, is what users feel.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A later client, parameter or reward formula is a different object from this paragraph.
The base chain remains the scarcity
The cut
A mass close of channels is a mass of Bitcoin transactions. Lightning moves everyday payments off-chain and concentrates chain use into openings, closings and disputes. A fee spike on Bitcoin is still a Lightning event.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The paper is about Bitcoin's scripting as it was specified. It is not a generic 'layer 2' for every chain.
05 Register
What has to be true
Model · Not re-measured
Both parties, or a watchtower, can get a penalty transaction confirmed in time.
Cryptography · Not re-measured
Hash preimages or adaptor secrets are revealed only when the previous hop is ready, so a hop cannot claim without passing the payment on.
Model · Not re-measured
Channel counterparties are chosen with some care. A channel with an offline peer is frozen capital.
Model · Not re-measured
The Bitcoin scripts used match what the paper's update rules expect. A soft-fork changes what is possible.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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 the desk 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
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.
