You've routed a payment through a Lightning channel, your counterparty goes dark, and you do exactly what the protocol says: broadcast a force-close transaction to recover your funds on-chain. Then you wait. The transaction sits. Blocks pass. Your timelock is burning down, and the transaction isn't confirming. Nothing is technically broken. The network is just being used against you.

That scenario has a name: transaction pinning. It is one of the more underappreciated attack surfaces in the Bitcoin stack, and understanding it requires getting comfortable with how mempools actually work.

The mempool is not a queue, it's a market

Bitcoin nodes don't confirm transactions. Miners do. Before that, transactions sit in each node's mempool, a local pool of unconfirmed transactions competing for block space, and miners rationally pick the highest-fee transactions first. So far, so obvious.

The complication is that Bitcoin supports chains of unconfirmed transactions. You can spend the output of a transaction that hasn't confirmed yet, and miners evaluate these chains together using a metric called ancestor fee rate: the combined fees of a transaction plus everything it depends on, divided by their combined weight. This is how child-pays-for-parent (CPFP) fee bumping works. Attach a high-fee child, and the parent gets pulled into a block alongside it.

Pinning exploits this same mechanics, but in reverse.

A Lightning force-close produces a commitment transaction with outputs governed by timelocks: your counterparty can't sweep their funds immediately, and you have a window to submit a penalty transaction if they tried to cheat. The commitment transaction itself is often pre-signed with a low fee, constructed weeks or months ago when fee rates were different. The design assumes you can CPFP it up to the current market rate when needed, the way you'd top up a parking meter before the warden comes around.

Here's where a malicious counterparty steps in. Before you broadcast your force-close, or immediately after, they broadcast a different version of the commitment transaction (also pre-signed, back when the channel was opened) and attach a large, low-fee-rate child transaction to it. Something like: a child that pays 1 sat/vbyte but adds 100,000 vbytes of weight to the package.

Now your CPFP is fighting that anchor. Most nodes enforce a mempool rule called the package size limit: by default, a chain of unconfirmed transactions cannot exceed 25 transactions or 101,000 virtual bytes. The attacker's bloated child has consumed most of that budget. Your high-fee child can't attach, because the package is already near its size ceiling. The commitment transaction is effectively stuck, pinned in the mempool at an uncompetitive fee rate, unable to be bumped.

Your timelock keeps counting down.

What's at stake in concrete terms

Call them Sofia and Marcus. They opened a channel six months ago. Marcus wants to steal: he broadcasts an old commitment transaction that shows a balance in his favor, one superseded by dozens of subsequent channel updates. Sofia has 144 blocks, roughly one day, to broadcast her penalty transaction and claim the entire channel balance. Standard Lightning security guarantee.

Marcus pins the commitment transaction. Sofia's CPFP attempts fail. If her penalty transaction doesn't confirm within those 144 blocks, and fees stay elevated enough that miners ignore the pinned package, Marcus wins. He recovers funds he was never entitled to, and Sofia's only recourse is to watch it happen.

The attack requires Marcus to pay something: he's burning fees on his bloat transaction. But the cost is asymmetric. If the channel held 0.5 BTC and Marcus spends a few thousand satoshis to pin it, the math is straightforward cruelty. This is not a theoretical edge case dressed up for a whitepaper. It is a rational profit opportunity for a sufficiently patient adversary, and that distinction should inform how seriously node operators treat channel sizing.

The fixes are real but incomplete

The Lightning and Bitcoin development communities aren't ignoring this. Two proposals have moved the needle meaningfully.

Anchor outputs, already deployed in most major Lightning implementations including LND and CLN, redesign commitment transactions so both parties can CPFP through a dedicated output, with pre-signed fees set near zero deliberately. This helps. It doesn't fully close the pinning window, because the package-size limit still applies.

Package relay, a proposed change to Bitcoin's peer-to-peer transaction propagation rules, would let nodes evaluate and relay transaction packages as a unit rather than individually. Paired with v3 transaction policy (a proposed opt-in rule that limits package size to exactly one parent and one child for certain transactions), this would make the bloat-child attack structurally impossible for transactions that opt in. Reading the two proposals together, the intent is clear: v3 policy is the rule, package relay is the enforcement mechanism that makes the rule mean something at the network layer.

Neither package relay nor v3 policy is active on mainnet. Both remain in proposal and testing phases. Anchor outputs are live and help at the margin.

So the honest picture is this: Lightning's force-close security guarantee is probabilistic, not absolute, and it degrades under adversarial mempool conditions. Are you running a node with large channels and a relaxed fee policy? That is a risk profile worth examining carefully. For small channels, the attack cost may deter most bad actors. For large channels, the risk is real enough that sophisticated node operators monitor mempool conditions and set aggressive fee policies during force-closes.

The protocol is fixable. It is just not fully fixed yet. And the gap between those two states is where the losses actually happen.