The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments

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.