The Problem With Signing a Transaction Before You Know the Fee

You signed the commitment transaction six weeks ago. Fees were low, the channel was healthy, everything was fine. Now the channel is contested, the mempool is a war zone, and that carefully constructed transaction is sitting unconfirmed while miners pick through a queue of higher-paying work. Your time-sensitive outputs, the ones with CSV (CheckSequenceVerify) timelocks that only start counting after confirmation, are going nowhere.

This is not a theoretical edge case. It is the central adversarial scenario that anchor outputs were designed to defeat.

What an Anchor Output Actually Is

A commitment transaction in a Lightning channel normally has two outputs: one for each party's balance. An anchor output adds two small additional outputs, one belonging to the local party and one to the remote party. Each anchor is typically 330 satoshis (the dust threshold for P2WSH outputs, chosen deliberately to avoid being pruned). Each is spendable immediately by its respective owner.

That's the whole structure. Two tiny outputs, one per side, attached to a transaction that might be moving millions of satoshis in the main balance outputs. It looks almost trivially simple. That's what makes it good engineering.

The spending script allows the owner to spend the anchor immediately, or allows anyone to spend it after a 16-block delay. That second clause prevents the anchors from permanently bloating the UTXO set if a channel closes cleanly and nobody bothers to sweep them.

So why does a 330-satoshi output matter? Because of Child-Pays-For-Parent.

Child-Pays-For-Parent, and Why Anchors Make It Work

Child-Pays-For-Parent (CPFP) is a fee-bumping mechanism built into Bitcoin's mempool logic. A miner evaluating whether to include a transaction looks at the package fee rate, not just the individual transaction. If transaction A has a low fee but transaction B spends one of A's outputs and carries a high fee, a rational miner includes both, because they have to include A to collect B's fee.

Without anchors, this doesn't help you. A contested commitment transaction's main balance output carries a CSV timelock (often 144 blocks, roughly one day) to allow the remote party to publish a revocation transaction if the broadcast was fraudulent. You cannot spend a timelocked output to create a CPFP child. The mempool won't accept it.

Anchors fix this by providing outputs with no timelock on the owner's side. Spend your anchor output the moment the parent enters the mempool, attach a high-fee child, and miners now have a reason to confirm the package.

Here is how it plays out in practice. Priya and Marco have a channel. Priya wants to force-close because Marco has gone offline. The commitment transaction was signed when the fee rate was 5 sat/vbyte; the mempool is now clearing at 80 sat/vbyte. Priya broadcasts the commitment transaction. It stalls. She then constructs a second transaction spending her anchor output, contributing almost no value (330 satoshis in, most of it consumed by the child's own fee), but setting a fee rate of 200 sat/vbyte on the child. The package fee rate across both transactions clears the threshold. The commitment transaction confirms. Priya's timelocked balance output starts its CSV countdown. Marco's anchor sits unspent and, after 16 blocks, anyone can sweep it.

The bump cost came entirely from Priya's external wallet. Not from the channel. That separation is the whole point.

The Carve-Out That Makes This Safe

There is a wrinkle in standard mempool policy that would otherwise break this entirely.

Bitcoin Core's mempool enforces a descendant limit: by default, a transaction can have at most 25 descendants, and the total package size cannot exceed 101 kilobytes. An adversary could spam the mempool with low-fee children of a commitment transaction, filling the descendant slots and blocking the victim from adding a CPFP bump. This is a transaction pinning attack, and it is not hypothetical.

To neutralise it, Bitcoin Core introduced the CPFP carve-out policy. It permits one additional child transaction to be added to a two-party package, provided that child has only one unconfirmed parent and is no larger than 1,000 vbytes. Each anchor output, being immediately spendable by exactly one party, qualifies as that carve-out slot.

The two-anchor design is not arbitrary. One anchor per party, one carve-out slot per party. Neither side can prevent the other from bumping. I think this is one of the more quietly clever design decisions in the Lightning spec, and it rarely gets the credit it deserves.

What People Get Wrong About Anchors

The most common misconception is that anchor outputs make presigned transactions immune to fee problems. They don't. They make fee problems solvable at broadcast time, which is a more modest and accurate claim.

Some limits worth holding in your head:

Anchors require liquid on-chain funds. If Priya's external wallet is empty, she cannot fund the CPFP child. The channel funds are locked in the commitment transaction itself. This is a real operational constraint, especially for routing nodes that might need to force-close multiple channels simultaneously during a fee spike.

The carve-out is mempool policy, not consensus. Miners are not obligated to follow it. In practice, major mining pools implement standard Core mempool policy, but this protection lives in the p2p layer. It is not enforced by Bitcoin's base consensus rules, and anyone who tells you otherwise is confused about the protocol stack.

Package relay is still rolling out. For CPFP to work reliably, the package (parent plus child) needs to propagate together across the network. Historically, if the parent's fee was too low, many nodes would reject it before it reached miners, meaning the child never arrived either. Package relay, being deployed in stages across Bitcoin Core versions, addresses this by allowing nodes to evaluate and forward transaction packages as a unit. Until it is universal, edge cases remain where CPFP bumping via anchors may not propagate as expected.

Zero-fee commitment transactions. The logical endpoint of the anchor design is a commitment transaction carrying a zero sat/vbyte fee, relying entirely on CPFP for confirmation. Cleaner in theory. It depends on package relay being fully operational across the network, which it is not yet.

Ask yourself this: if you had to force-close three channels tonight during a fee spike, would your hot wallet cover the CPFP costs? Most node operators have not done that arithmetic. They should.

The Broader Point

Anchor outputs solve a problem that looks, at first glance, like it should be unsolvable: you cannot modify a presigned transaction, you cannot predict future fee markets, and yet somehow the design needs to handle both. The anchor pattern threads those constraints the way a good plumber works around load-bearing walls: not by removing the obstacle, but by routing carefully around it.

For anyone running a Lightning node or thinking seriously about channel mechanics, check that your implementation supports anchor channels. LND, CLN, and Eclair all do, though sometimes behind feature flags or configuration options. Beyond that, hold a dedicated on-chain reserve for fee bumping.

The 330 satoshis in the anchor itself will not save you. The wallet funds to attach a meaningful child transaction will.