Bitcoin's RBF Carve-Out and Package Relay: What Happens When a Channel Close Gets Ugly
Your counterparty just went dark. The channel has funds in it, the mempool is running at 200 sat/vbyte, and the commitment transaction you need confirmed was signed back when fees were practically zero. You broadcast it, and every node it touches drops it at the door. The timelock is running. This is not a theoretical failure mode; it is the exact pressure point that two unglamorous mempool policy mechanisms were built to address: the CPFP carve-out rule and package relay.
Let's get into the mechanics.
The Problem That Needed Solving
Bitcoin's mempool enforces a limit on unconfirmed ancestor and descendant chains (the default is 25 transactions, with a total weight cap). The rule exists to keep nodes from drowning in enormous unconfirmed graphs.
Lightning's commitment transactions carry two outputs specifically so each counterparty can fee-bump via child-pays-for-parent (CPFP). Attach a high-fee child to your output, miners take the package, funds move. Simple enough in theory.
Except an adversary can break it. They pre-attach a sprawling, low-fee child transaction to their output before you broadcast yours, bloating the package to the ancestor/descendant limit. Your high-fee child can't attach. Your commitment transaction sits unconfirmed. Timelocks tick. This is transaction pinning, and for a while it was a genuine, practical griefing vector against Lightning nodes, not a whitepaper curiosity.
The carve-out rule was the first surgical fix.
How the CPFP Carve-Out Actually Works
Bitcoin Core introduced a specific exemption: if a transaction has exactly two outputs that could each carry one direct child, the mempool allows one extra child transaction even when the package is already at its descendant limit. That extra child is the carve-out. It is capped at 1,000 virtual bytes and must have no unconfirmed ancestors of its own.
In practice, a Lightning commitment transaction with standard `to_local` and `to_remote` outputs can always accept one fee-bumping child per party, regardless of what the other side has already pinned to their output. The bloat can't crowd out your slot.
Here is a concrete scenario. Alice and Bob have a channel. Bob broadcasts a stale commitment transaction, trying to steal funds Alice already spent. Alice's watchtower catches it and needs to get a penalty transaction confirmed fast. Bob, anticipating this, has pre-pinned the commitment output with a 24-descendant chain of 1-sat/vbyte dust. Under old rules, Alice's penalty child is locked out. Under the carve-out rule, Alice's child qualifies for the exemption: direct child of the commitment transaction, under 1,000 vbytes, no other unconfirmed parents. It enters the mempool. Alice bids the fee up, miners take the package, Bob's attempted theft collapses.
The carve-out is genuinely elegant. It is also, and I want to be direct about this, a patch on a deeper architectural problem rather than a solution to it.
What People Get Wrong About the Carve-Out
The most common misconception is that the carve-out fully solves transaction pinning. It doesn't. It solves one specific shape of pinning for one specific transaction structure.
The exemption applies only at the direct child layer. If your commitment transaction output has already been spent by an intermediate transaction (an HTLC-success or HTLC-timeout transaction, say), that intermediate transaction becomes the new parent for fee-bumping purposes. The carve-out exemption does not propagate down the chain. Your HTLC-resolution transactions, which appear constantly in contested closes with in-flight payments, are fully exposed to pinning again.
So picture a channel with three HTLCs in flight at force-close. You can carve-out fee-bump the commitment transaction itself. Each of those three HTLC output transactions is a separate graph, though, and each one is potentially pinnable by a patient adversary. The carve-out bought you one rung on the ladder. Not the whole ladder.
That gap is exactly what package relay is built to close.
Package Relay: Sending Transactions as a Bundle
Today, when you broadcast a transaction, nodes evaluate it in isolation. If its own feerate falls below the mempool's minimum threshold (which climbs during congestion), the node rejects it outright, even with a high-fee child already attached that would make the package attractive to miners. The child's generosity is invisible.
Package relay changes that. It lets a node receive and evaluate a group of related transactions together, as a single economic unit, before accepting or rejecting them. A commitment transaction paying 1 sat/vbyte plus its child paying 200 sat/vbyte can be assessed at their blended feerate. The package clears the floor together, or it doesn't.
For Lightning, the impact is concrete. A commitment transaction locked in at 1 sat/vbyte by negotiated channel parameters gets dropped at the relay door when the mempool floor rises to 10 sat/vbyte. No relay, no confirmation, no recovery. With package relay, you attach a CPFP child at 50 sat/vbyte, broadcast the pair, and nodes can relay and mine the bundle.
Ask yourself: how many Lightning nodes are running channels with commitment transactions signed months ago, when fees were low? The answer is most of them. This is not an edge case.
The version of package relay under active development for Bitcoin Core (the v3 transaction policy, part of the cluster mempool work) goes further still. It restricts the topology of relay-eligible packages specifically to prevent adversarial bloating. A v3 transaction signals that it opts into tighter descendant limits: one unconfirmed parent, one unconfirmed child, strict size caps. Pinning becomes geometrically harder because the adversary simply cannot build a bloating chain against a v3 transaction. The attack surface shrinks by design.
The carve-out is a hole punched through a wall to let air in. V3 package relay is rebuilding the wall with ventilation engineered from the start.
Where the Two Rules Meet
During a contested channel close with in-flight HTLCs, both mechanisms operate in sequence.
The commitment transaction benefits from the carve-out. Each party can CPFP it. But on a node running today without v3 support, the HTLC-resolution transactions remain pinnable. Package relay with v3 policy, once widely deployed, extends the protection down to those second-layer transactions. The two mechanisms are not alternatives; they are successive layers of the same fix, each addressing the attack surface the previous one left exposed.
The transition period matters here. A node running package relay but peered with nodes that don't support it won't get relay benefits even if the local mempool accepts the package. Propagation requires a critical mass of supporting nodes, which is why deployment is gradual and why Lightning implementations are already updating transaction construction logic to signal v3 compatibility ahead of full rollout.
If you're running a Lightning node, the practical upshot is this: verify your implementation has adopted anchor outputs (the output structure designed to work with the carve-out), and watch release notes for v3 and package relay support as it lands in Bitcoin Core and downstream Lightning software. Those updates exist because of exactly the mechanics described here. They are not cosmetic.
Mempool policy isn't a monolith handed down once and left to calcify. It's a living ruleset that adversarial conditions keep stress-testing, and the progression from carve-out to package relay is one of the cleanest examples of that evolution on record. The attacks got specific. The fixes got specific back. That's how this is supposed to work.