Revocation key

Every Lightning commitment transaction carries a revocation branch that nobody can sign for until one side reveals a per-commitment secret. BOLT 3 numbers those secrets from 281,474,976,710,655 downward, and the receiver can keep every one in an array of 49 slots. Publishing a state you already revoked lets your peer take the entire channel balance, which is why a seed phrase cannot back up Lightning.

How it works

A revocation key is deliberately built so that neither side of a channel can compute its private half alone.

When your node prepares a new commitment for your peer, it takes its own revocation_basepoint and your peer's per_commitment_point, multiplies each of the two by the SHA256 of the pair concatenated with that point written first, and adds the results. BOLT 3 states the property in one line: the construction ensures that neither the node providing the basepoint nor the node providing the point can know the private key without the other node's secret. The private key does not exist anywhere until the second half arrives.

That arrival is a message. Once your peer has checked your signature on its new commitment, it replies with revoke_and_ack, message type 133, carrying a 32 byte per_commitment_secret for the state it just retired plus the point for its next one. From then on you can compute the revocationprivkey for the old state, and your peer cannot take it back.

The key appears in two kinds of output. A to_local output is a P2WSH whose witness script reads OP_IF, the revocationpubkey, OP_ELSE, to_self_delay, OP_CHECKSEQUENCEVERIFY, OP_DROP, the local_delayedpubkey, OP_ENDIF, OP_CHECKSIG: the owner has to wait out to_self_delay blocks, while a holder of the revocation key spends immediately with the witness stack of a signature and a 1. Each HTLC output carries the same key hashed down to 20 bytes with RIPEMD160 over SHA256, and BOLT 5 requires the punishing node to sweep the cheater's HTLC-success and HTLC-timeout transactions with that key as well.

Storage is where the design gets clever. A channel can burn through 281,474,976,710,655 per-commitment secrets, one per state, all generated from a single unguessable 256 bit seed by flipping bits and hashing, with the index counting down rather than up. Because a secret whose index ends in trailing zeros derives every secret from there up to the next power of two boundary, the receiving node keeps only 49 value and index pairs and rebuilds the rest on demand. BOLT 3 also has the receiver re-derive its earlier secrets from each new arrival as a check, so a peer that quietly switched seeds is caught on the spot rather than at closing time.

Why this matters when you buy bitcoin

Revocation keys are the reason a Lightning balance behaves nothing like the on-chain coins an exchange sends you.

Of the 41 wallets reviewed on this site, the ones that put you on Lightning handle the state problem in visibly different ways, and the split explains their ratings. Phoenix runs a genuine self-contained node on the handset behind a standard BIP39 seed on a BIP84 path, and our review is explicit that the seed is the on-chain fallback rather than the channel: if ACINQ disappeared you would force close, wait roughly 720 blocks, about five days, and recover on chain with Electrum. Muun refuses the word list entirely and hands you an Emergency Kit file holding both multisig keys plus the output descriptors, on the published reasoning that a mnemonic backs up keys while its coins live in scripts a wallet also has to be told about. Wallet of Satoshi's default custodial mode removes the problem by removing you from it: the company holds every secret, which is why it carries a caution status and a 2.7 rating here, and why it could stop serving US customers on 23 November 2023 and withdraw the service across the European Union at the turn of 2026, leaving EU holders the self-custodial mode instead. BlueWallet is self-custodial on chain and rated 4.2 for it, while a Lightning balance there sits in an LNDHub account your on-chain recovery phrase does not cover.

The protocol does give you one safety net, and it is worth knowing precisely. If you reconnect carrying a stale state, channel_reestablish exposes it: your peer's message names a revocation number higher than you were expecting and carries back the last per-commitment secret you sent, which proves the claim is honest. BOLT 2 then says you must not broadcast your own commitment transaction and should send an error asking your peer to fail the channel instead. That is a rule honest software follows, not a consensus guarantee, and it protects you only while you refrain from publishing the stale state yourself. BOLT 5 puts the matching duty in plain terms: a node must not broadcast a commitment transaction for which it has already exposed the per-commitment secret.

Practically, the risk lives inside your receiving wallet and nowhere else. Buying on any of the 63 exchanges tracked here and withdrawing over Lightning does not expose you to it, because the exchange's channels are the exchange's problem. Your exposure starts the moment the coins land somewhere you are meant to be running the node.

The BOLT 3 test vector, key by key

BOLT 3 ships a worked derivation in its appendix, and reading it is the fastest way to see that both halves of a revocation key are load-bearing.

Start with a revocation_basepoint of 036d6caac248af96f6afa7f904f550253a0f3ef3f5aa2fe6838a95b216691468e2 and a per_commitment_point of 025f7117a78150fe2ef97db7cfc83bd57b2e2c0d0dd25eaf467a4a1c2a45ce1486. Hashing the basepoint first gives efbf7ba5a074276701798376950a64a90f698997cce0dff4d24a6d2785d20963, and hashing the point first gives cbcdd70fcfad15ea8e9e5c5a12365cf00912504f08ce01593689dd426bca9ff0. Multiply each point by the hash that leads with it, add the two results, and out comes the revocationpubkey 02916e326636d19c33f13e8c0c3a03dd157f332f3e99c317c141dd865eb01f8ff0.

Nothing about that public key leaks the private one. It appears only once the peer discloses the matching per_commitment_secret, 1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100, at which point the same two hashes combine with that secret and the basepoint secret to give the revocationprivkey d09ffff62ddb2297ab000cc85bcb4283fdeb6aa052affbc9dddcf33b61078110. One channel update, one disclosure, and a public key that was decoration a moment earlier becomes a claim on the whole output.

Revocation key vs seed phrase

A revocation key and a seed phrase are both secrets your money depends on, and only one of them can be written on paper.

A seed phrase is static. Twelve or twenty four words fix every key the wallet will ever derive, extra copies make you safer, and an old copy is exactly as good as a fresh one. Revocation secrets invert all three properties. They arrive one per channel update, inside revoke_and_ack, from the other side; the copies that matter are your peer's disclosures, which your own seed cannot regenerate; and an old copy of channel state is not a backup but a liability, because acting on it is indistinguishable from cheating. The 49 slot storage scheme exists precisely because these secrets change far too often to be written down.

The practical consequence is the warning every Lightning wallet repeats. Restore a Lightning wallet from words alone and start spending, and you have republished a state you already revoked, which is the one thing BOLT 5 forbids outright and the one thing your channel partner's revocation key has been waiting for.