Commitment Transaction

What Is a Commitment Transaction?

A commitment transaction is a Bitcoin transaction that spends the funding output of a Lightning Network payment channel. It encodes the current balance between two channel partners. Each partner holds their own version, pre-signed by the other party, so either side can unilaterally close the channel and settle on-chain at any time.

Think of a commitment transaction as a signed check that either party keeps in their pocket. You never need to cash it as long as both parties cooperate, but you always can. Every time a payment moves through the channel, both parties tear up the old checks and write new ones reflecting the updated balances.

The existence of commitment transactions is what makes the Lightning Network trustless. You don't need to trust your channel partner because you always hold a valid, broadcastable Bitcoin transaction that pays you your correct share of the channel funds.

How It Works

When two parties open a Lightning channel, they create a 2-of-2 multisig funding transaction on the Bitcoin blockchain. This funding output can only be spent with both parties' signatures. Commitment transactions spend this funding output, distributing the channel balance back to each party.

Asymmetric Structure

The key insight behind commitment transactions is asymmetry: each party holds a slightly different version. In Alice's commitment transaction:

• Alice's output (to_local) is locked by a timelock of to_self_delay blocks. She must wait before spending it. This output also has a revocation path that Bob can use immediately.
• Bob's output (to_remote) is spendable by Bob immediately with no delay.

Bob's commitment transaction is the exact mirror: his output is timelocked and revocable by Alice, while Alice's output is immediately spendable. This means the broadcaster always faces a delay on their own funds, while the counterparty can claim theirs right away.

The to_local script, as defined in the BOLT 3 specification, encodes both the timelock and the revocation path:

OP_IF
    <revocationpubkey>
OP_ELSE
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

This script gives two spending paths: the local party can spend after waiting to_self_delay blocks using their delayed key, or the remote party can spend immediately using the revocation key if the commitment has been revoked.

The Update Protocol

Every time a payment moves through the channel, both parties must update their commitment transactions. The protocol follows a strict sequence defined in BOLT 2:

1. Alice sends commitment_signed containing her signature for Bob's new commitment transaction, along with signatures for any in-flight HTLCs
2. Bob validates and stores the new commitment, then responds with revoke_and_ack, which reveals the per-commitment secret for his previous commitment (revoking it) and provides the point for his next commitment
3. Bob sends his own commitment_signed for Alice's new commitment
4. Alice responds with her own revoke_and_ack, revoking her previous commitment

After this exchange, both parties hold new commitment transactions reflecting the updated balance, and the old commitments are revoked. A channel can update millions of times over its lifetime. To handle this efficiently, Lightning uses a structure called shachain: a compact hash-based tree that stores all previous revocation secrets using only about 48 values, regardless of how many updates have occurred.

Transaction Structure

A commitment transaction follows a specific format defined in BOLT 3. The transaction uses version 2, with the locktime and sequence fields encoding an obscured commitment number. This hides the number of channel updates from on-chain observers while still allowing channel partners to identify revoked states.

A commitment transaction can contain up to six types of outputs:

• to_local: the broadcaster's balance (timelocked, revocable)
• to_remote: the counterparty's balance (immediately spendable)
• Offered HTLC outputs: outgoing payments currently in flight
• Received HTLC outputs: incoming payments currently in flight
• Anchor outputs: used for fee bumping after broadcast (if negotiated)

Outputs below the dust_limit_satoshis threshold are trimmed entirely, with their value added to the miner fee. The channel funder pays the commitment transaction fee, which is deducted from their output.

Why Asymmetry Matters: The Penalty Mechanism

The asymmetric structure exists to solve a fundamental problem: what stops someone from broadcasting an old commitment transaction where they had a higher balance? The answer is the penalty mechanism, enforced through justice transactions.

When a commitment transaction is revoked, the revoking party reveals a per-commitment secret. This secret, combined with the counterparty's revocation base point, allows the counterparty to derive the full revocation private key. If the revoking party later broadcasts that old commitment, the counterparty can use the revocation key to immediately sweep the cheater's timelocked output before the timelock expires.

The penalty is total: the cheater loses their entire channel balance, not just the disputed amount. This disproportionate punishment creates a strong economic disincentive against fraud. The to_self_delay parameter typically scales with channel capacity, giving larger channels longer detection windows.

Watchtowers can monitor the blockchain on behalf of offline users, detecting and responding to revoked commitment broadcasts automatically. This means the penalty mechanism works even when a channel partner is not online. For a deeper exploration, see the watchtower deep dive.

Anchor Outputs and Fee Management

Commitment transactions are signed in advance but may be broadcast much later, when on-chain fee conditions have changed significantly. This creates a problem: a commitment signed during low fees may be unconfirmable during a fee spike, and one signed during high fees wastes money if fees drop.

Anchor outputs solve this by adding small outputs (330 satoshis each) that either party can spend to attach a child-pays-for-parent fee bump. Each party gets their own anchor locked to their funding key. After 16 blocks, anyone can sweep unclaimed anchors to prevent permanent UTXO bloat.

Anchor outputs became the default for new channels across major implementations (LND, Core Lightning, Eclair) starting in 2021. All other outputs in anchor-style channels carry a 1-block CSV lock to prevent transaction pinning attacks.

A newer approach using version 3 (v3) transactions eliminates the need for per-party anchors entirely. Zero-fee commitment transactions replace the dual anchors with a single shared Pay-to-Anchor output and remove the update_fee message, which has historically caused force closes during fee spikes. This design relies on package relay and ephemeral dust support in Bitcoin Core.

HTLC Handling in Commitment Transactions

When payments are in flight through a channel, the commitment transaction includes HTLC outputs representing those pending payments. Each HTLC output has three spending paths:

• Revocation path: the counterparty can sweep it immediately if the commitment is revoked
• Success or timeout path: the appropriate party can claim it by revealing the preimage (success) or after the CLTV expiry (timeout)
• The success and timeout paths require a second-stage transaction (HTLC-success or HTLC-timeout), which itself outputs to a timelocked, revocable script

This two-stage design ensures that HTLC resolution does not extend the required timelock across the network. The second-stage transactions also carry the same revocation mechanism, preventing cheaters from profiting through HTLC manipulation. For more on how payments route through these structures, see the payment channels deep dive.

Why It Matters

Commitment transactions are the foundation of the Lightning Network's security model. Without them, off-chain payments would require trusting your channel partner to honestly report the current balance. The ability to unilaterally broadcast a commitment transaction at any time means you never depend on your counterparty's cooperation to recover your funds.

This design pattern extends beyond Lightning. Layer 2 protocols like Spark build on similar principles of pre-signed transactions and cryptographic enforcement to enable off-chain Bitcoin transfers with on-chain settlement guarantees. Understanding commitment transactions provides a foundation for evaluating any layer 2 scaling solution.

Use Cases

• Standard channel operation: every Lightning channel relies on commitment transactions to track balances off-chain while preserving the ability to settle on-chain at any time
• Dispute resolution: when channel partners disagree or one goes offline, commitment transactions provide the mechanism for unilateral force closes
• Routing security: intermediate nodes in a multi-hop payment hold commitment transactions with HTLC outputs that protect them from losing funds if adjacent nodes misbehave
• Channel rebalancing: operations like splicing and loop-in/loop-out interact with commitment transactions to resize channels or shift liquidity without closing them

Risks and Considerations

Stale State Broadcast

If a node loses data and accidentally broadcasts an old commitment transaction, it will be penalized just as if it had cheated intentionally. Running reliable backups and using the option_data_loss_protect or option_static_remotekey features can mitigate this risk.

Monitoring Requirements

The penalty mechanism only works if the cheated party detects the revoked broadcast before the timelock expires. This requires either staying online or using a watchtower service. Users who are offline for extended periods risk losing funds to an undetected fraudulent close.

On-Chain Footprint

When a commitment transaction is broadcast (during a force close), it consumes on-chain block space. If the commitment includes pending HTLCs, each one requires a separate second-stage transaction to resolve, further increasing the on-chain cost. During periods of high fees, force closes with many pending HTLCs can be expensive. Proper channel management helps minimize unnecessary force closes.

Complexity of Key Derivation

Commitment transactions use a sophisticated key derivation scheme where each state has unique keys derived from per-commitment points and base points. While this provides strong security guarantees, it adds implementation complexity. Bugs in key derivation or secret storage can lead to inability to close channels or missed penalty opportunities.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.