Penalty Transaction

What Is a Penalty Transaction?

A penalty transaction is a Bitcoin transaction that claims the entire balance of a Lightning channel when one party attempts to cheat by broadcasting an outdated commitment transaction. In the Lightning Network, each payment updates the channel state by creating a new commitment transaction and revoking the previous one. If a participant broadcasts a revoked state (one that no longer reflects the current balance), their counterparty can construct and broadcast a penalty transaction to seize all funds in the channel.

The penalty mechanism is the foundation of trustless state channels. Without it, there would be no consequence for broadcasting an old state that gives you a more favorable balance. The threat of losing everything makes cheating irrational: the potential gain from publishing a stale state is always smaller than the total channel balance you stand to lose.

The term "penalty transaction" is used broadly in Lightning documentation. Implementations like LND refer to the same concept as a "justice transaction," while the original Lightning whitepaper by Poon and Dryja used "breach remedy transaction." All three terms describe the same mechanism.

How It Works

Every time a Lightning channel updates its balance, both parties go through a two-phase commit protocol defined in the BOLT specifications (BOLT #2 and BOLT #3). Understanding this process is essential to grasping how penalty transactions become possible.

1. One party proposes a state change (adding or removing HTLCs, updating fees) by sending update messages
2. The proposer sends a commitment_signed message containing a signature for the counterparty's new commitment transaction
3. The receiver validates and responds with revoke_and_ack, which reveals the per_commitment_secret for the previous state and provides a new per_commitment_point for the next state
4. Once the secret is revealed, the previous commitment transaction is considered revoked: broadcasting it now gives the counterparty everything needed to construct a penalty transaction

The Revocation Secret Exchange

The cryptographic core of the penalty system is a blinded two-party key derivation. Neither party can independently compute the revocation key for a given commitment. The revocation public key is derived from both parties' contributions:

revocationpubkey =
  revocation_basepoint * SHA256(revocation_basepoint || per_commitment_point)
  + per_commitment_point * SHA256(per_commitment_point || revocation_basepoint)

The corresponding private key requires both the revocation_basepoint_secret (held by your counterparty) and the per_commitment_secret (held by you). When you send revoke_and_ack, you reveal your per-commitment secret, giving your counterparty the ability to derive the full revocation private key for that state. This is why broadcasting that state after revocation is punishable.

For storage efficiency, per-commitment secrets are generated using a shachain structure that requires only O(log N) storage: roughly 48 secrets cover the entire state space, rather than one secret per update.

Script Structure and the Timelock Window

The penalty is made possible by the structure of the to_local output in each commitment transaction. This output uses a conditional script with two spending paths:

OP_IF
    <revocationpubkey>        # Penalty path: immediate spend
OP_ELSE
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY    # Normal path: delayed spend
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

When you broadcast your own commitment transaction, you must wait to_self_delay blocks (typically 144 blocks, roughly one day, up to 2016 blocks or about two weeks) before you can spend the to_local output. Your counterparty, however, can spend it immediately using the revocation key via the OP_IF branch.

This asymmetry is the core of the penalty mechanism: the cheater is time-locked out while the honest party can act instantly. The timelock creates the window during which the penalty transaction can be broadcast. HTLC outputs in the commitment transaction have similar revocation paths, allowing the honest party to sweep those as well.

Constructing the Penalty Transaction

When a revoked commitment is detected on-chain, the honest party (or their watchtower) constructs a penalty transaction that spends all available outputs:

1. The to_local output, using the revocation key to bypass the timelock
2. Any offered HTLC outputs, using the revocation key
3. Any received HTLC outputs, using the revocation key

A single penalty transaction can resolve all these outputs. The BOLT specifications limit each party to 483 pending HTLCs, keeping the penalty transaction within standard size limits.

The Role of Watchtowers

The penalty mechanism only works if the honest party detects the breach. If you are offline when your counterparty broadcasts a revoked commitment, the timelock could expire before you respond, and the cheater would successfully steal funds. This is where watchtowers come in.

A watchtower is a third-party service that monitors the blockchain on your behalf. For each channel state update, you send the watchtower an encrypted penalty transaction and a half-transaction-ID locator. The watchtower cannot decrypt the transaction (preserving your privacy about channel balances) unless it detects a matching revoked commitment on-chain. When a match is found, the watchtower decrypts and broadcasts the penalty transaction automatically.

There are two models: altruistic watchtowers that return all recovered funds (minus on-chain fees), and reward watchtowers that take a negotiated portion as payment. For a deeper look at how watchtowers work, see our Lightning watchtowers explained research article.

Why the Penalty Must Be Severe

The penalty confiscates the entire channel balance, not just the disputed amount. This all-or-nothing design is deliberate and rooted in game theory:

• Disproportionate cost eliminates rational cheating: if the penalty were proportional to the disputed amount, there would be scenarios where the expected value of cheating is positive (for example, if the counterparty is likely offline). By making the penalty equal to the full balance, the expected cost always exceeds the expected gain.
• The penalty must exceed the maximum possible gain: since the most a cheater could gain is their counterparty's entire balance, the penalty must be at least that large. Taking the cheater's own balance as well ensures the penalty always exceeds the potential reward.
• Offline risk compensation: the honest party may incur costs to detect and respond to a breach, including watchtower fees, on-chain transaction fees, and opportunity cost. The full penalty compensates for these expenses.

Consider a channel where Alice and Bob each hold 0.25 BTC (0.5 BTC total). After Alice sends Bob 0.05 BTC, Alice attempts to broadcast the old state showing equal balances. If caught, Bob claims not just the 0.05 BTC owed but the full 0.5 BTC from the channel. The severity of this outcome makes the attempt irrational.

Empirical data supports the deterrent's effectiveness. A 2020 study by BitMEX Research identified only 241 justice transactions on the Lightning Network since its launch in late 2017, totaling just 2.22 BTC. Many of these were likely triggered by accidental broadcasts (database corruption, backup restoration) rather than intentional fraud.

Eltoo: A Penalty-Free Alternative

While the penalty mechanism is effective, it has significant drawbacks: nodes must store revocation data for every past state, accidental broadcast of an old state (after a crash or backup restore) triggers the same punishment as intentional fraud, and extending channels to three or more parties becomes complex. The eltoo proposal (also called LN-Symmetry) offers an alternative approach.

In eltoo, any later state can simply replace any earlier state on-chain without penalty. If someone broadcasts state #2, you respond by broadcasting state #5, which supersedes it. Publishing an old state only costs the on-chain transaction fee: there is no risk of losing your entire balance.

Eltoo requires a new sighash flag called SIGHASH_ANYPREVOUT (defined in BIP 118), which allows a signature to not commit to the specific UTXO being spent. This enables a pre-signed update transaction to be "rebound" to spend any prior state's output, even one that did not exist when the transaction was signed. BIP 118 has not yet been activated on Bitcoin mainnet and would require a soft fork. Research implementations have been tested on Bitcoin's signet.

For a broader comparison of Layer 2 enforcement mechanisms, see our research on payment channels from concept to implementation.

Use Cases

• Channel security enforcement: the primary use case is deterring fraud in Lightning payment channels, where the threat of total fund loss keeps participants honest during normal operations
• Watchtower services: penalty transactions are the mechanism through which watchtowers protect offline users, enabling a market for channel monitoring services
• Force-close dispute resolution: when a channel is closed uncooperatively, the penalty mechanism ensures that the on-chain settlement reflects the true final state rather than a stale one
• Game-theoretic foundation for the Lightning Network: penalty transactions make trustless, off-chain Bitcoin payments possible by providing a credible on-chain enforcement backstop

Risks and Considerations

Accidental Breach Risk

The penalty mechanism does not distinguish between intentional fraud and accidental broadcast of an old state. If your node crashes and you restore from a stale backup, broadcasting the outdated commitment transaction triggers the same total loss as deliberate cheating. This "toxic state" problem is one of the most significant UX challenges for Lightning node operators. Modern implementations mitigate this with static channel backups (SCBs) that trigger a cooperative close rather than broadcasting old commitments.

Online Requirement

To enforce a penalty, you must detect the revoked commitment transaction and broadcast the penalty transaction before the to_self_delay timelock expires. If you are offline for the entire delay period and have no watchtower monitoring on your behalf, a cheater can successfully steal funds. This creates a liveness requirement that does not exist with standard on-chain Bitcoin transactions.

Storage Overhead

Nodes must retain revocation secrets for every prior channel state. While the shachain structure makes this compact (roughly 48 secrets per channel), nodes with many channels and frequent updates still accumulate meaningful storage over time. This contrasts with eltoo, which requires storing only the latest state.

Multiparty Channel Complexity

The penalty mechanism was designed for two-party channels. Extending it to channel factories or multiparty channels introduces significant complexity: a single party's breach could affect all other participants, and coordinating revocation across multiple parties is challenging. This limitation is another motivation behind eltoo and alternative Layer 2 designs like Spark, which uses a different trust model to avoid these constraints entirely.

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.