Justice Transaction

What Is a Justice Transaction?

A justice transaction is a Bitcoin transaction that sweeps all funds from a Lightning channel when one party attempts to cheat by broadcasting a revoked commitment transaction. It serves as the ultimate enforcement mechanism in Lightning's security model, transforming attempted theft into total loss for the attacker.

The name "justice" reflects its punitive nature: rather than simply preventing fraud, it punishes the fraudster by transferring their entire channel balance to the victim. This harsh penalty exists by design. The threat of losing everything creates a strong economic disincentive against cheating, even when the potential gain might be small.

Justice transactions are also called penalty transactions, breach remedy transactions, or revocation transactions. All these terms describe the same mechanism: using a revocation secret to claim funds from a cheating counterparty's outdated commitment transaction.

Why Justice Transactions Exist

Lightning Network channels work by exchanging signed commitment transactions that could be broadcast at any time to close the channel. Each time a payment moves through the channel, both parties create new commitment transactions reflecting the updated balances and revoke the previous ones.

The problem: old commitment transactions remain valid Bitcoin transactions. Nothing stops a malicious party from broadcasting an old state where they had more funds. If Alice and Bob opened a channel where each had 0.5 BTC, then Alice paid Bob 0.3 BTC, Alice could try to broadcast the original 50/50 state instead of the current 20/80 split.

Without a penalty mechanism, Lightning would require trust or constant online monitoring. Justice transactions solve this by making fraud unprofitable. When parties revoke old states, they exchange revocation secrets. If someone broadcasts a revoked state, the other party uses that secret to construct a justice transaction claiming everything.

The game theory is straightforward: attempting to steal 0.3 BTC risks losing 0.2 BTC. No rational actor takes this bet. The mere existence of justice transactions prevents most fraud attempts from ever occurring.

How It Works

Understanding justice transactions requires knowing how Lightning commitment transactions are structured. Each commitment transaction has asymmetric outputs designed to enable penalty enforcement:

Commitment Transaction Structure

When Alice and Bob have a channel, each holds a slightly different version of the current commitment transaction. Alice's version gives Bob his funds immediately but makes Alice wait through a timelock (typically 144-2016 blocks). Bob's version is the mirror: Alice gets immediate access while Bob waits.

The delayed output uses a special script that allows spending in two ways:

• After timelock: The original owner can spend after the delay expires
• With revocation key: Anyone with the revocation secret can spend immediately

This dual-path script is the foundation of justice transactions. The delayed path lets honest parties close channels normally. The revocation path enables punishment.

The Revocation Process

Each time the channel state updates:

1. Both parties create new commitment transactions with updated balances
2. Both parties exchange signatures on the new commitments
3. Both parties reveal their revocation secrets for the old commitments, making them unsafe to broadcast

The revocation secret is a private key component that, when revealed, allows the counterparty to derive the full revocation key. Revealing this secret is irreversible. Once shared, that old state is permanently revoked because the counterparty can now execute the punishment path.

Executing Justice

When someone broadcasts a revoked commitment:

1. The broadcast appears on the Bitcoin blockchain in the mempool
2. The honest party detects this (directly or via watchtower)
3. The honest party constructs a justice transaction using the stored revocation secret
4. The justice transaction spends both the cheater's delayed output AND any pending HTLCs, sweeping everything to the honest party
5. The justice transaction broadcasts before the timelock expires (critical window)

The timelock on the cheater's output is essential. It provides a window for the honest party to react. Once the timelock expires, the cheater could spend their output and the justice opportunity is lost.

Watchtowers and Delegated Justice

Justice transactions require someone to actually monitor the blockchain and react to fraud attempts. This creates a practical challenge: users must be online, watching every block, ready to broadcast justice transactions within the timelock window.

Watchtowers solve this by providing outsourced monitoring. Users share encrypted justice transaction data with watchtowers, who monitor the chain on their behalf. If a watchtower detects a breach, it decrypts and broadcasts the justice transaction, claiming a small fee from the swept funds.

The watchtower model preserves privacy through clever cryptography. Users share blob data that watchtowers can only decrypt if they see a specific transaction on-chain. This prevents watchtowers from learning about channels that never experience breaches.

Watchtower Security Considerations

• Multiple watchtowers: Using several watchtowers provides redundancy. If one misses a breach, others may catch it.
• Watchtower liveness: A watchtower that goes offline during a breach cannot protect you. Choose reliable services.
• Fee economics: Watchtowers must be compensated. Some take a percentage of recovered funds, others charge subscription fees.

Technical Implementation

Justice transactions involve specific Bitcoin Script constructions defined in BOLT 3. The key scripts enable the dual-path spending that makes penalties possible.

Revocable Output Script

The to_local output in a commitment transaction uses a script similar to:

OP_IF
    # Revocation path: counterparty can spend immediately with revocation key
    <revocationpubkey>
OP_ELSE
    # Normal path: owner can spend after timelock
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

The revocation pubkey is constructed from both parties' keys. Only when the revocation secret is revealed can the counterparty derive the full private key needed to spend via the revocation path.

LND Implementation

In LND, justice transactions are handled automatically by the breach arbiter subsystem. When LND detects a broadcast of a revoked commitment, it:

1. Retrieves the corresponding revocation data from its database
2. Constructs justice transactions for all spendable outputs
3. Broadcasts immediately with elevated fee rates to ensure confirmation
4. Logs the breach and outcome for audit purposes

HTLC Outputs

Justice transactions must also sweep any pending HTLCs on the revoked commitment. Each HTLC output has its own revocation path, allowing the honest party to claim these funds regardless of whether they originally belonged to the local or remote side.

Limitations and Edge Cases

Timing Requirements

Justice transactions must confirm before the cheater's timelock expires. During periods of high on-chain fees or network congestion, broadcasting with sufficient fee priority becomes critical. A justice transaction that arrives too late is worthless.

Most implementations use aggressive fee estimation for justice transactions, often paying premium rates. The entire channel balance is at stake, so overpaying fees is rational.

Offline Risk

If both the user and their watchtower(s) are offline during a breach and the timelock period, funds can be stolen. This is Lightning's fundamental liveness requirement: someone must be watching. The longer the timelock, the more time to react, but also the longer funds stay locked during legitimate closes.

Data Loss Scenarios

Justice transactions require the revocation secrets from all previous states. If this data is lost (corrupted database, backup failure), the ability to punish old states is lost with it. Robust backup strategies are essential for Lightning node operators.

Toxic Waste Problem

Every channel state generates revocation data that must be stored forever while the channel is open. Long-lived, high-activity channels accumulate significant storage requirements. This "toxic waste" must be carefully managed to prevent data loss that could enable unpunished fraud.

FAQ