Galtland Index

The Lightning Network Paper

3 min read

The Lightning Network Paper

The Lightning Network Paper is Joseph Poon and Tadge Dryja’s 2016 draft “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.”

Scaling Problem

Poon and Dryja begin with the constraint that every on-chain Bitcoin transaction must be propagated and validated by the network. If all global payments had to appear on chain, block size, bandwidth, and storage demands would push validation toward specialized operators and custodians.

The paper frames this as a scaling-versus-decentralization problem. Bigger blocks can raise throughput, but at sufficient scale they make full validation expensive and encourage trust in centralized parties. Lightning instead tries to keep ordinary payments off chain while preserving Bitcoin’s blockchain as the final enforcement layer.

Payment Channels

The paper’s base object is the bidirectional payment channel. Two parties fund a 2-of-2 multisignature output on chain, then exchange signed commitment transactions that represent the current balance. They do not broadcast each update. They hold enforceable states that can be submitted if cooperation fails.

Old states are discouraged through revocation and penalty logic. If a party broadcasts a stale commitment, the counterparty can use a breach-remedy transaction to take the channel funds within the dispute window. This makes the current off-chain state credible because cheating can be punished on chain.

HTLC Routing

A single channel only connects two parties. The network design adds hashed timelock contracts. An HTLC pays if the recipient reveals a preimage to a known hash before a timeout; otherwise the sender can recover the funds after the timeout.

Routing chains HTLCs across several channels with decrementing timelocks. Alice can pay Dave through Bob and Carol by using the same hash condition across the path. Dave’s preimage disclosure lets each upstream participant claim from the prior hop. If a hop fails, only the affected channel has to go on chain; cooperative channels can settle by off-chain novation.

Settlement Backstop and Tradeoffs

Lightning does not replace the blockchain. It changes how often the blockchain is used. Cooperative updates stay local to channel counterparties, while the blockchain remains the court of last resort for channel closure, stale-state punishment, and HTLC timeout or execution.

The tradeoff is operational complexity. Liquidity must be allocated to channels, paths must be found, timelocks must be chosen safely, keys may need online availability for routing nodes, and forced expiration spam is a systemic risk. Lightning Network covers the concept; the paper proposed the architecture.

See Also

Sources

Graph View

Backlinks