Revocation Key

What Is a Revocation Key?

A revocation key is a cryptographic key that enables the penalty mechanism in Lightning Network payment channels. When two parties update their channel state—sending payments, receiving payments, or routing HTLCs—they create new commitment transactions. Each old commitment transaction must be "revoked" to prevent a dishonest party from broadcasting it later to steal funds.

The revocation key is the enforcement tool. When you revoke an old state, you give your counterparty a secret that, combined with their own key material, creates a revocation key capable of spending all outputs in that old commitment transaction. If you ever broadcast that revoked commitment, your counterparty can use the revocation key to take everything.

This mechanism is fundamental to Lightning's security model. Without revocation keys, there would be no trustless way to update channel balances. Either party could broadcast whichever historical state favored them most. Revocation keys transform a potential free-for-all into a system where honesty is the only rational strategy.

Why Revocation Matters

To understand why revocation keys are necessary, consider how Lightning channels work. A payment channel is essentially a shared Bitcoin UTXO with a 2-of-2 multisig. Both parties must sign to spend it. They create "commitment transactions" that specify how to divide the funds if the channel closes.

The problem: every time the balance changes, a new commitment transaction is created. After ten payments, there are ten different valid commitment transactions, each allocating different amounts to each party. Any of these could theoretically be broadcast to close the channel.

Without revocation, a malicious party could wait until the channel balance favors them, then broadcast an old commitment transaction from that favorable moment—even after subsequent payments changed the balance. This would be theft.

Revocation keys solve this by making old commitment transactions toxic. Yes, you can broadcast them—Bitcoin doesn't prevent it—but doing so hands your counterparty the key to take all your funds. The economic incentive flips from "maybe I can steal" to "if I try to cheat, I lose everything."

How Revocation Works

The revocation mechanism involves a careful exchange of secrets during each channel update. Here is the step-by-step process:

Initial State

When a channel opens, both parties generate a chain of revocation secrets using a deterministic derivation scheme. They do not share these secrets yet—they hold them for future revocations.

Creating a New Commitment

When state changes (a payment is made), both parties create new commitment transactions reflecting the updated balances. Each commitment transaction has two versions: one for Alice to hold and one for Bob to hold. The versions are asymmetric—structured so that the holder faces a time delay before claiming their own funds, while the counterparty can claim immediately if a revocation key is available.

Exchanging Revocation Secrets

Before the new state is considered valid, both parties exchange the revocation secrets for the previous state. Alice gives Bob her revocation secret for state N-1, and Bob gives Alice his. Now each party can construct the revocation key for the other's old commitment transaction.

The Revoked State

After this exchange, the old commitment transactions are "revoked." They still exist and could technically be broadcast, but doing so would be financial suicide. The counterparty, armed with the revocation secret, can construct a breach remedy transaction that sweeps all funds.

Commitment Transaction Structure

The asymmetric commitment structure is key to making revocation work. When Alice holds a commitment transaction:

• Alice's output: Has a timelock (typically 144 blocks / ~1 day). Alice must wait before spending. This delay gives Bob time to detect and respond to cheating.
• Bob's output: Immediately spendable by Bob. No penalty risk for Bob since this is Alice's commitment.
• Revocation path: Alice's timelocked output can alternatively be spent immediately using the revocation key. If Alice broadcasts a revoked state, Bob uses the revocation key to take Alice's funds before the timelock expires.

Technical Implementation

The revocation key system uses clever cryptographic constructions to enable deterministic key derivation while maintaining security. The BOLT 3 specification defines the exact derivation.

Key Derivation

Revocation keys are derived using elliptic curve point multiplication. Each party has a "revocation basepoint" (a public key) and generates per-commitment "revocation secrets." The actual revocation public key for a commitment is computed as:

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

This construction ensures that neither party can compute the revocation private key alone. You need both the revocation basepoint's private key and the per-commitment secret. Only after the per-commitment secret is revealed can the full revocation private key be derived.

Storage Optimization

Channels can have thousands of state updates. Storing every revocation secret would require significant space. Lightning implementations use a shachain structure that allows storing all secrets efficiently in O(log n) space. The shachain derives secrets from a single seed, and receiving secrets in reverse order allows compact storage while still enabling derivation of any previous secret.

Script Mechanics

The actual Bitcoin script for a revocable output typically looks like this (simplified):

OP_IF
    # Revocation path - counterparty can claim immediately with revocation key
    <revocationpubkey>
OP_ELSE
    # Normal path - owner must wait for timelock
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

The OP_IF branch allows immediate spending with the revocation key. The OP_ELSE branch enforces the timelock for normal (non-breach) spending by the output owner.

The Breach Remedy Transaction

When a counterparty broadcasts a revoked commitment transaction, the honest party executes a "breach remedy" or "justice" transaction. This transaction uses the revocation key to claim all outputs before the cheater's timelock expires.

Detection

The honest party (or their watchtower) monitors the blockchain for any commitment transactions from the channel. When one appears, they check: is this the current state, or a revoked state? If revoked, they have the revocation secret and can respond.

Claiming Funds

The breach remedy transaction spends the cheater's timelocked output using the revocation key. Because the revocation path has no timelock, it can be broadcast immediately. The honest party should use a high fee to ensure confirmation before the cheater's timelock expires.

HTLC Outputs

If the revoked commitment had pending HTLCs, those outputs also have revocation paths. The breach remedy transaction can claim HTLC outputs too, again using the revocation key. This prevents cheaters from recovering any funds, even from in-flight payments.

Security Considerations

Liveness Requirements

Revocation only works if the honest party detects the breach and responds before the timelock expires. This creates a liveness requirement: you must monitor the blockchain or delegate that monitoring to a trusted watchtower. Going offline for extended periods without a watchtower is risky.

Watchtower Integration

Watchtowers are services that monitor the blockchain on your behalf. You share encrypted breach remedy data with the watchtower. If a revoked commitment appears, the watchtower can decrypt and broadcast the remedy transaction. This allows mobile users and intermittently-connected nodes to maintain channel security.

Fee Considerations

Breach remedy transactions must confirm before the cheater's timelock expires. In high fee environments, this could require significant fees. Lightning implementations typically anchor outputs and use CPFP (Child Pays For Parent) to bump fees on commitment transactions, ensuring breach remedies can be prioritized.

Backup Complexity

Revocation secrets must be stored carefully. If you restore from an old backup that doesn't include the latest revocation secrets, you cannot construct breach remedy transactions for recent states. Worse, you might accidentally broadcast an old commitment transaction yourself, triggering your counterparty's penalty mechanism against you.

FAQ