When the Exit Door Gets Jammed
You've decided to force-close a Lightning channel. The counterparty is uncooperative. You broadcast your commitment transaction at what looks like a sensible fee rate, lean back, and wait. An hour passes. Then two. The transaction idles in the mempool like a letter sitting on the wrong desk, and meanwhile, time-sensitive outputs are ticking toward expiry. You reach for CPFP to push the fee higher. Rejected. That is transaction pinning, and it is one of the more quietly vicious problems in Bitcoin's second-layer stack.
The short answer: pinning lets a malicious counterparty anchor your transaction to the mempool at a fee rate too low to confirm, while simultaneously blocking your ability to raise that fee through standard mechanisms. Fee bumping becomes unreliable not because the tools are broken in isolation, but because an adversary can exploit mempool rules against you.
Now let's get into why.
How Mempools Become Weapons
Bitcoin nodes don't just hold unconfirmed transactions. They enforce a layered ruleset about which transactions they'll accept and relay. Two rules matter most here.
First, RBF (Replace-By-Fee): a transaction can be replaced by a higher-fee version, but only if the replacement pays enough to cover both its own fee and the incremental relay cost of evicting everything it conflicts with. Second, CPFP (Child-Pays-For-Parent): you attach a child transaction that pays a high enough fee to make the combined package attractive to miners.
Both are legitimate, well-designed tools. The problem is that Lightning's commitment transactions often have outputs controlled by both parties, and the party who doesn't want the channel to close cleanly can use their own outputs to build a structure that defeats your fee-bumping attempts before you even try.
Here is the specific mechanic. Bitcoin's mempool limits how large a transaction cluster can grow. Under the long-standing default rules, the combined size of an unconfirmed transaction and all its descendants cannot exceed 101 kilovirtualbytes (kvB). If a malicious counterparty attaches a large, low-fee child transaction to the shared commitment transaction, they can bloat that cluster right up to the limit. Your CPFP attempt gets rejected outright: the mempool won't accept one more byte of descendants. You're locked out of the fee market.
This is the pin.
A Worked Scenario: Martina and the Stalled Close
Martina runs a Lightning routing node. She opens a channel with a counterparty, call him Derek, who turns out to be adversarial. Martina wants to force-close because Derek has gone offline at a strategically inconvenient moment and an HTLC on their channel is set to expire in roughly 40 blocks.
Martina broadcasts the commitment transaction at 5 sat/vB, expecting confirmation within a few hours. Derek, who is not actually offline, immediately broadcasts a child transaction from his own output on the same commitment transaction. That child is 95 kvB of low-priority data, paying 1 sat/vB. The cluster sits at 99.8 kvB, just under the 101 kvB limit, and Derek has structured his child to be cheaper to mine than almost anything in Martina's fee-bumping range.
Martina tries CPFP from her own output. Rejected. Cluster full. She tries to RBF the commitment transaction itself, but to do that legitimately she must pay enough to evict Derek's entire 95 kvB child, because RBF rules require her replacement to cover the relay cost of all conflicting transactions. At even 2 sat/vB, that's a large absolute fee just to get back to square one.
The HTLC expiry ticks closer. If it lapses before the commitment transaction confirms, Derek can potentially claim funds he has no right to. Martina is watching a protocol-level theft play out in slow motion, and the mempool rules are the instrument.
Why the Existing Tools Fall Short
The tools themselves aren't naive. RBF was designed specifically for fee escalation. CPFP was recognized as a practical mechanism early in Bitcoin's scaling discussions. Neither was designed with an adversarial second-layer counterparty in mind: someone who shares outputs on the transaction you're trying to bump and who has strong financial incentives to delay your confirmation. That is an important distinction, and I think it gets glossed over too often in protocol documentation.
The RBF pinning variant is particularly nasty because it exploits the absolute-fee requirement. A high-feerate transaction with a small size can be pinned by a large, low-feerate transaction. Your replacement needs to beat the absolute fee of the thing being evicted, not just its feerate. Derek's bloated 95 kvB child at 1 sat/vB represents 95,000 satoshis in absolute fees that Martina must exceed just to clear the path. That's a meaningful sum, especially if the HTLC at risk is smaller.
CPFP fails for the cluster-size reason already described. The combination of both attacks is worse than either alone.
There's also a subtler issue. Lightning's commitment transaction format, through most of the protocol's history, had "to-local" and "to-remote" outputs spendable immediately by the remote party. That design choice, made for sensible reasons around simplicity, inadvertently handed adversaries the tool they needed to pin.
What the Protocol Is Actually Doing About This
This is not a secret crisis. Bitcoin and Lightning developers have been working on pinning mitigations for years, and several concrete improvements are worth naming.
Anchor outputs (formalized in BOLT 3 and widely deployed) were a direct response. Instead of giving each party immediately-spendable outputs that could bloat the cluster, anchor outputs give each party a small, dedicated output specifically intended for fee-bumping via CPFP, while other outputs are encumbered by a CSV (CheckSequenceVerify) delay that prevents spending until the transaction confirms. This limits how much of the cluster an attacker can fill before you've had a chance to bump.
Anchor outputs help. They don't fully solve the problem. An attacker can still attach children to the anchor outputs themselves, and the 101 kvB cluster limit still applies.
Package relay is the next piece. Currently, Bitcoin nodes evaluate transactions individually when deciding whether to admit them to the mempool. A high-fee child doesn't help its low-fee parent get in if the parent is below the mempool's minimum feerate floor. Package relay would allow nodes to evaluate a parent-and-child together as a unit, so a well-funded CPFP can actually get the parent admitted in the first place. It's a significant mempool policy change, and it's been in active development and testing.
Cluster mempool is a more fundamental redesign of how Bitcoin Core organizes the mempool. By tracking transaction relationships as explicit clusters and sorting them by mining score rather than individual feerate, cluster mempool makes it possible to reason about and limit pinning attacks more precisely. It also enables cleaner RBF rules that don't require matching absolute fees against bloated low-feerate descendants.
V3 transactions (a new transaction version with stricter topology rules) pair with package relay to create a tightly constrained environment where each transaction can have at most one unconfirmed parent and one unconfirmed child. That kills the bloating attack: you cannot attach 95 kvB of descendants to a V3 transaction. The Lightning spec is being updated to use V3 for commitment transactions in the relevant contexts.
None of these fixes are retroactive. Older channel types remain exposed until both parties upgrade.
The Honest Caveat: Pinning Is Probabilistic, Not Guaranteed
So how worried should you actually be? It depends entirely on what you're running.
Pinning is not a trivially easy attack to execute. The adversary needs to watch the mempool in real time, respond faster than the victim, pay real fees for the pinning transactions, and correctly anticipate which outputs to bloat. In practice, many force-closes happen against counterparties who are simply offline or unresponsive, not actively malicious. Those closes work fine.
The risk concentrates in specific scenarios: large HTLCs near expiry, channels with counterparties who have a financial motive to delay, situations where the victim is operating on a tight confirmation deadline. Casual Lightning users closing small channels with cooperative counterparties are unlikely to encounter this. Routing nodes handling significant liquidity are a different matter, and I'd argue that anyone operating at that scale without understanding pinning mechanics is taking on risk they haven't priced.
Also worth noting: the attack costs the attacker real fees. The economics favor the attacker only when the value at risk exceeds their pinning cost. That doesn't make the attack rare, but it does make it targeted, not random.
The Fee Market Is the Battlefield
What makes pinning genuinely interesting from an engineering standpoint is that it isn't a cryptographic break. No private keys are exposed. No hash function is weakened. The attack lives entirely in the mempool policy layer, a set of rules that nodes adopted for perfectly sensible anti-spam and incentive-compatibility reasons, now turned against the people those rules were meant to protect.
The fixes, similarly, aren't cryptographic. They are policy changes, topology constraints, relay protocol upgrades. Unglamorous, incremental, necessary work. In any contested channel close, the fee market is not a backdrop. It's the terrain.