Commitment transaction

Every Lightning payment replaces both sides' commitment transactions with a new pair, and the old pair is revoked rather than deleted. BOLT 3 fixes the expected weight of an anchor channel commitment at 1,124 weight units plus 172 for each payment still in flight. Holding one means holding an exit you can take alone, at a fee your peer agreed to weeks earlier.

How it works

A commitment transaction has exactly one input, the channel's 2-of-2 funding output, and its outputs are the current split of that money.

Two of them exist at any moment, one per peer, and they are deliberately not the same transaction. Each copy delays its own holder's payout behind an OP_CHECKSEQUENCEVERIFY lock of to_self_delay blocks while paying the other side sooner, so whoever broadcasts is the one who waits. Under option_anchors even the other side is not instant: the to_remote output carries a one block CSV lock, added so that no peer can jam the commitment by attaching cheap child transactions to it.

The transaction hides its own counter. BOLT 3 sets the version field to 2, takes the 48 bit commitment number, XORs it with the lower 48 bits of SHA256 over the two payment_basepoint values from open_channel and accept_channel, then splits the result across two fields: the upper 24 bits go into the input's sequence behind the byte 0x80, the lower 24 into the locktime behind 0x20. Both peers recompute it in a moment. Anyone else watching the chain sees two arbitrary looking numbers and cannot count how many payments the channel carried.

The funder pays for the exit. Before any output is laid out, the base fee is subtracted from whichever side funded the channel, and with option_anchors two fixed anchor outputs of 330 satoshis each come out of that same side as well. Outputs are then sorted by value smallest first, then by scriptPubKey compared bytewise, then by cltv_expiry for HTLC outputs, so both peers arrive at a byte identical transaction without ever sending it to one another.

Anything too small to be worth writing down is not written. BOLT 3 calls these trimmed outputs: an HTLC whose amount, minus the fee its own second stage transaction would cost, falls under the owner's dust_limit_satoshis gets no output at all, and the money becomes miner fee instead of anyone's balance. The thresholds BOLT 3 lists are Bitcoin Core's: 330 satoshis for pay to witness script hash, 294 for pay to witness pubkey hash, 240 for pay to anchor. Those are a floor rather than the setting itself, and BOLT 3 tells anchor channels to sit above it, because on those channels the second stage transaction pays no fee and so stops contributing to trimming at all.

The newest form of the transaction throws the built in fee away. Where zero_fee_commitments applies, the version field becomes 3, feerate_per_kw is fixed at 0, and one shared_anchor output carrying the pay to anchor script OP_1 <0x4e73> is added at that 240 satoshi limit. Anybody can spend it, so the commitment reaches a block by child pays for parent at whatever the fee market costs on the day, rather than at whatever it cost when the pair was signed.

Why this matters when you buy bitcoin

The commitment transaction is where a Lightning balance stops being a number on a screen and becomes satoshis minus fees, and two of its rules cost real money.

The first is trimming. Small amounts inside a channel are not rounded, they are deleted, and the spec's own worked example hands 1,800 satoshis of in flight payments to the miner because each one fell below the dust limit plus its second stage cost. That puts a floor under what is worth moving onto Lightning at all. Phoenix, the ACINQ wallet in our reviews, charges 1,000 satoshis to create a channel and states that recovering from a force close takes roughly 720 blocks, about five days. A channel funded with a few thousand satoshis is arithmetic that never works out.

The second is that the fee inside a commitment transaction was chosen when it was signed. The funder's balance was docked at that day's feerate_per_kw, and if the mempool has moved since, the transaction sitting in your wallet may not confirm at the price it carries. Anchors exist because of exactly this, and zero_fee_commitments exists to move the decision to broadcast time instead.

Neither rule reaches you if somebody else holds the channel. Strike, rated 4.6 in our exchange reviews, is Lightning native and custodial while your balance sits in the app, and Coinbase prices its Lightning withdrawals below an on chain send for small amounts and above it for large ones. What you trade away is documented in the wallet reviews: Wallet of Satoshi, rated 2.7 and flagged caution, stopped serving United States customers on November 23, 2023, and later withdrew its custodial Lightning service across the European Union as the MiCA transition periods closed in. No commitment transaction of yours existed to fall back on.

Walking through the BOLT 3 fee example

BOLT 3 publishes one worked fee calculation, and following it end to end shows where a channel's money actually goes.

The setup is a feerate_per_kw of 5,000, a dust_limit_satoshis of 546, and four payments in flight: offered HTLCs of 5,000 and 1,000 satoshis, received HTLCs of 7,000 and 800 satoshis. At that fee rate an HTLC timeout transaction costs 3,315 satoshis and an HTLC success transaction costs 3,515.

Weight starts at 724, the figure for a channel without option_anchors, which is the shape this whole example assumes. The offered 5,000 satoshi HTLC clears 546 plus 3,315, so it gets an output and the weight rises to 896. The offered 1,000 satoshi HTLC does not clear it and is trimmed. The received 7,000 satoshi HTLC clears 546 plus 3,515, so it gets an output and the weight rises to 1,068. The received 800 satoshi HTLC is trimmed.

The base fee is 5,000 multiplied by 1,068 and divided by 1,000, or 5,340 satoshis, taken out of the funder's output alone. The fee a miner actually collects is 7,140 satoshis, because the two trimmed HTLCs are added on top. Of 13,800 satoshis in flight, 1,800 stop existing as anyone's balance, and the total can climb further still if the funder's own output drops below the dust limit once the fee comes out of it.

Commitment transaction vs penalty transaction

A commitment transaction pays out a split both peers signed; a penalty transaction takes the whole channel from a peer who published a split they had already revoked.

The two spend different things. A commitment transaction spends the funding output. A penalty transaction spends the outputs of a commitment transaction that turned out to be stale, using the revocation key its holder handed over when that state was replaced. The to_local script writes both futures into one output: one branch needs the delayed key after to_self_delay blocks, the other needs a revocation signature and works with no delay whatsoever.

Commitment transaction vs force close

A commitment transaction is an object you hold; a force close is the event of somebody broadcasting one.

The distinction matters because you need not be the one acting. If your peer force closes on a current state, their copy pays your side without any move from you, subject only to the one block CSV lock that anchor channels put on the to_remote output. Your own copy is the fallback for a peer who has gone quiet, and it is the copy that makes you wait out the delay. Holding a commitment transaction is normal, continuous and free; broadcasting one is an event you would rather never have.