中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC050
A payment channel lets participants update an agreed allocation without placing every update on the base chain. The important question is what evidence each participant holds when cooperation stops. A displayed balance, an unfinished exchange of messages and an enforceable commitment are different things.
Lightning provides a concrete setting for learning this distinction. Its channel protocol uses off-chain cooperation and on-chain enforcement. Understanding the connection requires more than saying that small payments are bundled together: the learner must distinguish current commitments, revoked commitments, conditional payments and the transactions that resolve a channel. BOLT 0: Introduction
This guide is a reading and reasoning exercise. All amounts below are invented units, and the examples contain no usable transaction, key, invoice or payment instruction. They do not establish that a service is available or suitable in any jurisdiction.
Choose your reading route
In this guide
- 1. Begin with the claim a balance is making
- 2. Two commitments are not one shared editable document
- 3. Work through a ten-unit channel
- 4. Revocation changes consequences, not the past signature
- 5. Closure card A: both sides cooperate
- 6. Closure card B: a current unilateral commitment
- 7. Closure card C: a revoked old commitment
- 8. Closure card D: an interrupted update
- 9. A route has directional constraints
- 10. What an evidence checklist should record
- 11. Classroom exercise and worked answers
- 12. Frequently asked questions
- Sources and next reading
For the central idea, read sections 1–4. For a review of failure handling, continue through the closure cards and evidence checklist. For a classroom activity, calculate the allocation trace and route bottleneck before opening the answers.
The lesson concerns the relationship between a private update and a possible chain outcome. For the institutional background to authorisation, clearing and settlement, see How Payment Systems Move Money. That broader account supplies useful vocabulary, while the exercise here examines a specific cryptographic enforcement arrangement.
Back to contents · Next section
1. Begin with the claim a balance is making
Suppose a screen reports that A has five units in a channel. Five of what, under which state, and usable in which way? The answer could mean a current allocation, a proposed update, a spendable amount after restrictions, or a simplified display that hides pending conditions. Those interpretations need different evidence.
A good first question is therefore: “Which channel record does this number summarise?” A second is: “What can A demonstrate without B sending another message?” A third is: “What further chain events or waiting conditions would be needed?” Together they convert an attractive interface claim into an examinable protocol claim.
Keep three columns in a notebook: proposed, completed off-chain, and resolved on-chain. A row should move between columns only when the evidence supports that transition. A notification saying that a request was sent belongs in the first column unless the relevant completion conditions are also established.
These columns are a learning aid, not a substitute for the implementation’s full state machine. In particular, a real update can be at different stages for the two participants. Compressing everything into one green or red status can conceal exactly the distinction that matters during an interruption.
Back to contents · Next section
2. Two commitments are not one shared editable document
In the Lightning model, each participant holds the other participant’s signature for its own commitment transaction. The two commitments describe corresponding channel obligations but have different ownership perspectives. A completed update involves commitment and revocation steps, rather than overwriting one common signed file. BOLT 0: Commitment terminology
The peer protocol explicitly tracks how an update reaches each side’s commitment and how previous commitments are revoked. A signature received for one stage does not establish that every required stage has finished. The protocol also allows the two commitment transactions to be out of sync during operation. BOLT 2: Normal operation
For classroom calculations, we will label completed allocation snapshots S0, S1 and S2. These are worksheet labels. They are not a claim that Lightning maintains one globally shared sequence number with exactly these values, nor that a base-chain node selects whichever label is largest.
This distinction prevents a common modelling error. It is convenient to draw two balances beside one state label, but the drawing leaves out the evidence that makes the allocation enforceable. Use the drawing to check arithmetic; use the protocol records to assess authority and completion.
Back to contents · Next section
3. Work through a ten-unit channel
Our fictional channel has a fixed gross allocation of ten units. Assume an established funding output and correctly held baseline commitments. Each transition below is supplied as fully completed, with the necessary evidence retained by the appropriate parties. No update is merely proposed.
We exclude fees, reserves, dust thresholds, anchors, pending conditional payments, rounding and all changes to channel funding. The numbers are gross accounting allocations, not a prediction of actual Bitcoin transaction outputs or net amounts received after a close.
- S0: A has 6 and B has 4. Total: 10.
- First completed update: A transfers 2 to B. S1 is A4, B6.
- Second completed update: B transfers 1 to A. S2 is A5, B5.
Check each direction separately. The first update subtracts two from A and adds two to B. The second subtracts one from B and adds one to A. Across both updates, A’s net change is minus one and B’s is plus one. Each snapshot preserves the total.
Now ask a different question: does the arithmetic tell us that S2 was completed? No. Completion was an explicit assumption of the exercise. Without that assumption, the same numbers could be written in an unsigned note. Correct arithmetic establishes internal consistency, not the existence of the required signatures and revocation information.
An auditor should preserve both conclusions: “The supplied completed state allocates five each” and “The worksheet alone is not evidence that a live channel reached that state.” Neither conclusion needs to weaken the other.
Back to contents · Next section
4. Revocation changes consequences, not the past signature
A later update does not make an earlier signature disappear from the other participant’s storage. In the revocation-based commitment arrangement examined here, a relevant output returning to the broadcaster is delayed, while the other party can use the revocation path when it has the required material. BOLT 3 defines the delayed and revocation alternatives for the to_local output. BOLT 3: Commitment outputs
This explains why “the old state is invalid” is a dangerous shortcut. It can sound as though Bitcoin automatically rejects an old signed commitment because somebody privately agreed a newer allocation. The relevant mechanism instead makes publication of a revoked commitment answerable through the specified output paths.
In our completed trace, A’s S0 allocation is six, while A’s S2 allocation is five. An obsolete A-side commitment associated with S0 could therefore look attractive to A if one inspected only the gross allocation. That observation identifies a possible incentive; it does not prove that a particular person intends misconduct.
The response must refer to the exact revoked commitment and the applicable spend conditions. Saying “B remembers five” is insufficient. Saying “B has a screenshot of S2” is also insufficient. The worksheet asks whether the required enforceable evidence exists, and whether it can be used in time.
Back to contents · Next section
5. Closure card A: both sides cooperate
The first card says that A and B agree to end the channel using an appropriate cooperative closing transaction. In the supplied S2 accounting, their gross allocations are five each. The actual transaction still needs its own agreed outputs, fees and valid authorisation.
The correct conclusion is limited: cooperation can resolve the funding output through a jointly agreed close. It is not necessary to treat a cooperative close as an allegation that someone used an obsolete state. BOLT 5 discusses mutual closing separately from unilateral and revoked-transaction handling. BOLT 5: Mutual close handling
Suppose a report says, “The peers agreed, so the base chain has already settled it.” That report skips evidence. Agreement and chain inclusion are separate events. The reviewer should identify the actual transaction, the relevant chain observation and the confirmation assumptions before describing the chain outcome.
A signed plan can be useful before inclusion, but its usefulness should be named accurately. It is evidence of an agreed transaction, not evidence that a particular block already contains it.
Back to contents · Next section
6. Closure card B: a current unilateral commitment
The second card says that communication stops after completed S2. A uses its current commitment. The situation calls for current-commitment handling, not a presumption of a revoked-state attempt merely because B did not cooperate in closing.
The broadcaster’s delayed output has a relative waiting condition in the commitment format. BOLT 3 describes the to_self_delay mechanism; its exact spending conditions matter more than an informal promise that a balance will be “available soon”. BOLT 3: to_local output
For this card, do not invent a calendar date or claim that all outputs become usable together. Our toy excludes the details needed to calculate that result. The useful answer is a dependency statement: current commitment evidence, chain inclusion, applicable output conditions and subsequent resolution must each be established.
This is still a meaningful result. An incomplete answer that clearly identifies missing inputs is stronger than a precise-looking date derived from assumptions nobody supplied. In a technical review, precision includes knowing where the calculation must stop.
Back to contents · Next section
7. Closure card C: a revoked old commitment
The third card supplies an old A-side commitment associated with S0 and states that it has been revoked through the completed update process. B has the correct revocation material and observes the transaction. The card asks whether Bitcoin simply substitutes S2 because its worksheet number is higher.
The answer is no. The appropriate analysis follows the revoked commitment’s output conditions and the available remedy. BOLT 5 describes handling of revoked transactions and their outputs; timely on-chain handling is part of the protection. BOLT 5: Revoked transaction close handling
Do not turn “a remedy exists” into “the remedy happened”. Detection, possession of the right evidence, construction of a valid response and effective inclusion are separate requirements. A message sitting in a queue is not the same as a confirmed spend. Nor should this simplified example promise that B automatically receives exactly all ten gross units.
The practical lesson is about an evidence chain. The old transaction must be identified correctly; its revocation status must be established; the response must use the relevant conditions; and the chain result must be observed. Missing any link changes the claim that can responsibly be made.
Back to contents · Next section
8. Closure card D: an interrupted update
The fourth card removes the exercise’s completion assumption. A screen displays the proposed S2 balances, but the retained records demonstrate only an intermediate stage. The reviewer has no evidence that the complete exchange needed for the claimed update finished.
The right classification is “insufficient evidence to call S2 completed”. It is not “S2 is definitely impossible”, because additional records could resolve the question. It is also not “use whichever balance the interface displays”, because that would replace the protocol evidence with a presentation choice.
Write down the last established stage on each side, the exact missing message or persisted record, and the competing interpretations that remain possible. Avoid prescribing a live recovery action from the simplified worksheet. Real channel recovery depends on precise implementation state and current commitments, not a generic instruction to restore the oldest backup.
This card demonstrates a broader habit: when evidence is incomplete, narrow the conclusion rather than fill the gap with the most convenient story. That habit applies to every distributed system whose user interface combines several asynchronous operations.
Back to contents · Next section
9. A route has directional constraints
A channel network introduces another question: can a particular route carry an amount in the required direction? Consider a separate toy route A → B → C. Its supplied usable capacities are three units from A to B and one unit from B to C. Assume no fees, pending conditions or other constraints for this calculation.
A request for two units cannot fit this single route because the second hop has only one usable unit. The first hop’s spare capacity does not move into the second channel merely because both involve B. The route bottleneck is the smaller supplied directional capacity: one.
If the second hop’s usable capacity changes to four while the first stays at three, the bottleneck becomes three. A two-unit amount then fits these capacity constraints, but that does not prove payment completion. Correct conditions, cooperation, message delivery and the other protocol requirements still matter.
The example says nothing about whether another route or a multi-part construction exists. Neither is supplied. Likewise, a public figure for a channel’s total capacity does not by itself tell the observer how much is currently usable in one direction.
Lightning connects channels using conditional payments, including hash and time conditions. The introduction explains how these conditions support forwarding across participants. That mechanism is richer than asking B to accept an unconditional promise and voluntarily pay C later. BOLT 0: Conditional payments and forwarding
Back to contents · Next section
10. What an evidence checklist should record
Use this checklist to review a description, not to operate a wallet:
- Identify the network, channel and funding reference. Do not combine records from different channels.
- Separate gross allocation, usable directional capacity and predicted closing outputs.
- Identify whose commitment is being described and whether the update is fully established.
- Distinguish current, revoked and uncertain records. Preserve the reason for each classification.
- State the closure path and the evidence supporting it.
- Record the chain observation and relevant output conditions separately from a local interface status.
- Identify missing records, monitoring assumptions and unresolved outcomes.
A strong report also identifies its exclusions. “No pending conditional payments in this example” makes the scope understandable. “All channels work like this” would erase precisely the complications the exclusion avoids.
Retained evidence deserves attention because a channel is stateful. Possessing a general account identifier is not equivalent to possessing all records needed to interpret every historical update. Nevertheless, this lesson is not a backup or recovery recipe: implementation-specific recovery procedures must not be inferred from its invented snapshots.
Back to contents · Next section
11. Classroom exercise and worked answers
Question 1. Starting from S0, apply the two completed updates. What is S2, and what is A’s net change?
Answer. A6/B4 becomes A4/B6, then A5/B5. A’s net change is minus one. The ten-unit total is preserved at every stage.
Question 2. A has an old signature. Does that fact alone establish that the corresponding commitment is current?
Answer. No. Signature validity and current channel status answer different questions. The reviewer needs the relevant update and revocation history.
Question 3. An observer correctly recognises a revoked commitment but cannot demonstrate any included response. May the report say that the remedy completed?
Answer. No. Recognition supports diagnosis. It does not establish the resulting chain spend or its confirmation status.
Question 4. On the supplied three-and-one route, would reversing the request automatically provide three units of capacity from C to A?
Answer. No. Reverse-direction capacities were not supplied. They cannot be copied from the forward-direction figures.
Question 5. A proposed update balances arithmetically, and the interface displays it. What additional question must be answered?
Answer. Whether the required protocol stages and persisted evidence establish completion. Arithmetic and display alone cannot supply that answer.
Back to contents · Next section
12. Frequently asked questions
Does every off-chain update appear as a separate Bitcoin transaction?
No. The purpose of the channel arrangement is to support updates through off-chain cooperation, with chain transactions providing the enforcement setting. Do not infer that this removes all dependence on the base chain. BOLT 0
Is a unilateral close evidence of cheating?
No. The relevant distinction is the status and contents of the commitment. A current unilateral close and publication of a revoked commitment require different analysis.
Can I infer a safe offline period from this lesson?
No. No operational timing recommendation is supplied. Actual response requirements depend on the negotiated conditions, chain behaviour, retained evidence and implementation.
Does a route-capacity calculation prove that a payment will succeed?
No. It tests one necessary constraint in the supplied model. It does not establish all conditions or the completed result.
Back to contents · Next section
Sources and next reading
Primary references checked on 12 October 2026. These links point to the moving master branch of the BOLT specifications; they are not claims that every optional feature shown is deployed everywhere.
- BOLT 0: Introduction and terminology, for channels and conditional forwarding.
- BOLT 2: Peer protocol, especially the normal-operation update stages.
- BOLT 3: Transactions, for commitment output conditions.
- BOLT 5: On-chain handling, for the different closure cases.
The allocations, route capacities and diagnostic cards are original teaching examples. Their purpose is to make the evidence requirements visible, without presenting a simplified sketch as a complete operational protocol.