Transaction Pinning Attack

Transaction pinning attack is a class of Bitcoin denial-of-service technique that abuses the very mempool policies designed to protect nodes, turning them into a weapon that makes fee-bumping a target transaction prohibitively expensive or outright impossible. The attacker does not steal coins directly; instead, they "pin" an unfavorable version of a transaction in mempools so that the honest party cannot replace it or accelerate it before a deadline passes. The danger is most acute in multiparty time-sensitive protocols like the Lightning Network, where a channel participant must reliably confirm a commitment or justice transaction before a timelock expires. If the honest side cannot bump the fee in time, the attacker can walk away with funds that the protocol assumed could always be reclaimed.

Why pinning works

Bitcoin nodes enforce mempool limits so that an attacker cannot exhaust their memory with endless chains of unconfirmed transactions. Historically the default limits allowed a package of up to 25 unconfirmed transactions or roughly 101 kvB of descendants. Replace-by-fee (RBF) rules add another constraint: a replacement must pay a higher absolute fee than the original transaction and all of its descendants, not merely a higher feerate. Each of these safety rails becomes a lever. An attacker who can attach children to a shared transaction — which is exactly the situation in Lightning, where both parties can spend outputs of the same commitment transaction — gets to choose how expensive replacement becomes.

Common pinning vectors

Two patterns dominate. In the absolute-fee pin, the attacker attaches a large, low-feerate child to the target transaction. Because RBF demands that a replacement outbid the total fees of everything it evicts, the honest party must now pay for the attacker's junk descendant just to replace their own transaction — a cost the attacker sets almost arbitrarily. In the package-limit pin, the attacker saturates the descendant count or size limits with a chain of children, so no further child-pays-for-parent (CPFP) bump can even enter the mempool; the honest party's anchor spend is simply rejected. If the attacker already operates a service that naturally produces long transaction chains, mounting the attack can be effectively free, and the low-feerate children may never confirm — they exist only to block.

The layered defenses

The ecosystem has answered with successive rounds of protocol engineering. The CPFP carve-out rule reserved room for one extra fee-bumping child even when descendant limits were otherwise full. Anchor outputs gave each Lightning party its own dedicated bumping point on the commitment transaction, so neither side depends on outputs the other can pollute. More recently, TRUC (topologically restricted until confirmation, the v3 transaction policy) caps unconfirmed trees to a single small child, ephemeral anchors provide a keyless, fee-only bumping output, and package relay lets a parent and its fee-paying child be evaluated together instead of one at a time. Cluster mempool work in Bitcoin Core reorganizes how the mempool tracks related transactions, closing further corner cases that pinning leaned on. Together these shrink the attack surface dramatically for protocols that opt in.

Why it matters to a node runner

Pinning is the threat model that motivated much of modern fee-bumping design, and it is a clean illustration of a recurring Bitcoin lesson: policy rules that are individually sensible can interact adversarially. If you run Lightning infrastructure — even a single home node routing sats beside your miners — your funds' safety during a force-close depends on these mitigations, which is one more reason to keep node software current rather than treating it as fire-and-forget. See mempool policy for the rules being gamed, ancestor/descendant limits for the specific thresholds, and standardness for the broader machinery that decides which transactions relay at all.