Glossary / Lightning & layer 2
Penalty transaction
- What is a penalty transaction?
- A penalty transaction is the on-chain sweep that takes every output of a Lightning channel when your peer publishes a revoked commitment, signed with the revocation key you already hold.
Lightning channels are policed by their two participants, and the penalty transaction is the enforcement. BOLT 5 gives that sweep a 160 byte witness for the main balance output, and says to split it per output if it has not confirmed 18 blocks before the cheater's timelock expires. If you keep coins in channels, this transaction is what stands between you and a peer who rewinds your balance.
How it works
A penalty transaction spends outputs whose owner has already handed you the right to take them.
Every time the balance in a channel moves, each side gives up the secret behind the state it is replacing. Hold that secret and you can derive the revocation private key for your peer's old commitment transaction, which is the key that unlocks their side of it. BOLT 5 puts the consequence in one line: once a node discovers a commitment transaction for which it has a revocation private key, the funding transaction output is resolved. Nothing is left to negotiate.
What you sweep depends on what the stale commitment carried. The specification makes you resolve the cheater's main output with the revocation key, resolve each payment they offered in one of three ways (spend the commitment with the revocation key, spend it with the payment preimage if you know it, or spend their HTLC-timeout transaction once they publish it), and resolve their HTLC-success and HTLC-timeout transactions with the revocation key as well. It also tells you to pull the preimage out of the input witness while you are in there, because a payment you were about to lose may still be claimable from the hop before you.
Three witness shapes cover all of that, and BOLT 5 gives the size of each: 160 bytes for the main balance output, 243 bytes for an offered payment, 249 bytes for an accepted one. Add the 164 weight of the input itself and each claimed output costs 324, 407 or 413. The remainder of the transaction is 53 bytes of non-witness data plus a 2 byte witness header. You may also fold in your own main output from the same commitment, which adds 272 and is there mainly to cut the fee you pay.
Two things a penalty transaction is not. It is not automatic: bitcoin punishes nobody, and the sweep happens only if software you run, or software you hired, sees the stale transaction confirm and reacts before the cheater's timelock runs out. It is also not free. The sweep pays the going rate like any other transaction, so a channel holding less than the cost of emptying it is not worth defending, whatever the rules allow.
Why this matters when you buy bitcoin
A penalty transaction defends you only in a wallet where you hold commitment transactions of your own, which rules out most of the easy Lightning apps.
The 41 wallet reviews on this site split along exactly that line. Phoenix runs a real self-custodial Lightning node on the handset, so the punishment machinery belongs to you and so does the duty of watching: ACINQ's recovery route has you force closing and waiting roughly 720 blocks, about five days, before channel funds are yours on chain. BlueWallet is bitcoin-only and unusually capable on chain, yet its Lightning side is an account on an LNDHub server, and unless that server is yours the operator can move those coins, so no commitment transaction of yours exists to punish anybody with. Wallet of Satoshi is custodial in its default mode too, which is part of why it sits at a 2.7 rating here rather than in a recommendation.
Read that as a trade rather than a verdict. Custodial Lightning deletes cheating peers from your threat list and replaces them with one company that can freeze or withdraw the service. Self-custodial Lightning hands you the penalty transaction and the obligation to be awake. The mistake that catches people on either side is reusing an old seed backup: twelve words restore on-chain coins and know nothing about which channel state is current, so the commitment you publish is stale and the penalty transaction that follows is aimed at you.
A revoked close on a Phoenix channel
Picture a Phoenix channel with three payments still in flight when the node at the other end publishes a commitment from last week.
Your software spots the txid, derives the revocation key and builds one sweep. Its weight is 324 for the cheater's main output, 413 for each of the three accepted payment outputs, 272 for folding in your own main output, four times 53 bytes of transaction body and a 2 byte header: 2,049 weight units, or about 512 virtual bytes. Their money sits behind the relative timelock the two sides agreed when the channel opened, and delays of that kind run in days rather than minutes: recovering from a force close in Phoenix takes roughly 720 blocks, about five days. Yours is spendable the moment a miner takes your transaction.
BOLT 5 also works out the ceiling. Against a maximum standard weight of 400,000 and the largest input at 413, a single penalty transaction reaches 966 payment outputs, twice the 483 pending payments per side that the peer protocol already allows, so even a completely stuffed channel can be emptied in one go.
Then comes the reason not to. Where the channel uses anchor outputs, the cheater's own payment transactions are signed with SIGHASH_SINGLE and SIGHASH_ANYONECANPAY, so they can attach their own inputs and pin your combined sweep in the mempool long enough for the timelock on their main output to expire. If confirmation has not arrived by the time that output is within the security delay of expiring, a window BOLT 5 leaves to node policy while recommending 18 blocks, you are told to break the job up: one penalty transaction per revoked output, fee bumped until each confirms. Under zero fee commitments every one of those must also stay inside the 10,000 virtual byte limit that version 3 transactions carry, or it may never reach miners.
Penalty transaction vs force close
A force close is any unilateral exit from a channel, while a penalty transaction is the reply to a dishonest one.
Most force closes are dull. A peer went offline, a payment deadline approached, somebody's node published the current state, and both sides get the balance they were owed once the delay passes. A penalty transaction exists only in the narrow case where the published commitment had already been revoked, and it takes the entire channel rather than a share. Every penalty transaction follows a force close, and almost no force close produces one.
Penalty transaction vs watchtower
A penalty transaction is a signed bitcoin transaction, while a watchtower is a machine that sits waiting to broadcast one on your behalf.
The tower stores a short prefix of the revoked txid and a blob it cannot decrypt until that transaction turns up in a block. The sweep inside was built and signed by your own node, paying out to an address chosen before anything went wrong, so hiring one costs you no keys. Mixing the two up produces the wrong worry. Running no tower does not weaken the penalty transaction at all; it means nobody is awake to send it while your laptop is shut.