Mastering the Lightning Network

Chapter 3 of Mastering the Lightning Network builds its first channel with Alice and Bob, the coffee customer and cafe owner who carry the book's running examples. Alice wants to place 100,000 sats in a 2-of-2 multisignature output shared with Bob, yet if she broadcasts that funding transaction first, Bob can withhold his signature and hold her coins hostage. The remedy reorders the steps: before she broadcasts the funding transaction, Bob signs a transaction refunding Alice from the shared output, so her exit exists before her coins move. That sequence sets the habit the book keeps training: read a payment as negotiated channel state and ask which signed transaction lets each party leave.

Andreas M. Antonopoulos, Olaoluwa Osuntokun and René Pickhardt wrote the book for O'Reilly in 2021, and the O'Reilly edition is the official place to read it. It moves from introductory chapters and node operation into a long protocol section, with early chapters suited to anyone comfortable with Bitcoin transactions and later ones aimed at developers who want protocol detail. This recommendation draws on the preface, the introductory material and chapters 1, 3, 12, 16 and 17 in the authors' repository at commit 54453c7, and the repository text may differ from the printed edition.

Each payment then replaces that signed split with a new commitment, so after Alice pays Bob 30,000 sats both hold one paying 70,000 sats to her and 30,000 to him. The book says Alice keeps ownership throughout, and what the protocol secures is a unilateral exit backed by signatures she already holds, which rests on key control and stays separate from legal title. Because the older refund still pays her everything, each party's output in its own commitment waits behind a timelock, and only when an update completes does each side hand over revocation information for its previous commitment, letting the counterparty sweep that delayed output if the old state appears.

That penalty deters only when someone carries it out: a revoked commitment that confirms on chain remains a valid transaction, so Bob's node, or a watchtower acting for him, has to notice it and confirm a justice transaction before Alice spends her delayed output, and once the delay expires the two spends race, with Bob's claim valid until hers confirms. Chapter 3 says a missed penalty lets the theft stand. Its claim that only the latest revocation secret needs storing is a simplification, since current BOLT 3 describes a compact store of up to 49 (value, index) pairs, because a secret can regenerate only earlier secrets whose indices share its prefix, and the maintained BOLTs remain the reference for implementation.

Chapter 12 is the strongest reason to read the book. Capacity is the amount funded into the 2-of-2 output and balance is each partner's share, while liquidity is whatever part of a balance can move in one direction once the channel reserve and pending HTLCs are subtracted. Announcements carry keys, signatures and a short channel ID identifying the funding output, from which nodes derive capacity, and channel updates add each side's fee and timelock policy. Balances stay private to the partners, since publishing them would expose payment flows and flood the network with updates. Every node assembles its own graph from these messages, and a sidebar on map and territory warns that the graph is always partly incomplete or stale; pathfinding sits outside the BOLTs, leaving the algorithm to each implementation.

The worked case sends one million sats from Selena to Rashid across six nodes, with fees and timelock requirements accumulating backward from the recipient because each hop expects to receive more than it forwards and to hold a longer timelock. That arithmetic rules out Selena's channel to Xavier, whose liquidity covers one million sats and falls short once downstream fees are added. Her first attempt through Alice and Bob fails at the hop from Bob to Rashid, so her node lowers its estimate for that channel and succeeds on a longer route through Alice, Bob, Xavier and Yan. Splitting the payment into parts of 600,000 and 400,000 sats makes both the Xavier channel and the failed hop usable.

The reader's gain is judgment about what the network reports. A temporary channel failure suggests liquidity was short for that amount at that moment, yet a peer with its own incentives supplies the report, and it loses reliability as other payments shift balances. The chapter's probability model assumes uniformly distributed liquidity and independent channels; it explains why small parts and short paths help, and its percentages are outputs of that model, to be kept distinct from measured success rates. Multipart atomicity likewise depends on a compliant recipient that waits for every part before releasing the preimage, since nothing cryptographic stops a dishonest receiver from claiming parts early.

Chapter 16 brings the same discipline to privacy by defining adversaries first. An honest-but-curious forwarder sees amounts and the hops on either side of it, while two colluding nodes on one route can link their HTLCs through the shared payment hash. A node's limited channel connections, read against a partial view of the graph, can support inferences about where a payment began or ended. Cross-layer analysis extends that reach by clustering on-chain funding and settlement transactions with nodes, though the chapter notes false positives and the complication CoinJoin adds. Announcing a Tor onion endpoint lets a routing node avoid publishing its IP address, yet payment correlation and on-chain links remain, so the authors frame Lightning's privacy gain as a smaller audience for each payment, short of unlinkability.

The availability material explains why tying up a channel is cheap. A forwarding node commits capital and an HTLC slot to every payment it relays and, under the protocol the book describes, earns fees only on settlement, so an attacker can hold payments until they time out and tie up slots or much liquidity at little cost. The authors compare the problem to Bitcoin's minimum relay fee and report that remedies were still under debate, which leaves routing operators to treat forwarding as a service whose capacity others can exhaust without paying.

The book suits programmers, system architects and technically motivated node operators who already understand Bitcoin and want to know where authority and liquidity sit inside a channel. As a 2021 snapshot with mid-2021 graph statistics and multipart payments described as recently deployed, it should yield to the maintained specification wherever the two differ. Chapter 3 says every invoice has a fixed amount, for instance, whereas BOLT 11 at the commit cited above lets an invoice omit the amount and treats a stated amount as a minimum. For custody and backups, follow your implementation's maintained documentation.