Transaction Pinning Attacks on Bitcoin: Exploiting Mempool Rules for Profit

Bitcoin transactions do not confirm the moment they are broadcast. They first enter the mempool, a holding area where unconfirmed transactions wait to be included in a block. The mempool is governed by relay rules: policies that determine which transactions nodes accept, propagate, and prioritize. Transaction pinning is a class of attacks that exploit these relay rules to prevent a victim from getting their transaction confirmed in time, or to make fee-bumping prohibitively expensive.

For simple wallet-to-wallet payments, pinning is mostly an annoyance. For time-sensitive protocols like the Lightning Network, Discreet Log Contracts, and other Layer 2 systems, pinning can mean the difference between recovering funds and losing them. This article explains how pinning works, which protocols are vulnerable, and the multi-year effort to close these attack vectors at the protocol level.

How Replace-by-Fee Rules Create Pinning Opportunities

Transaction pinning exploits Replace-by-Fee (RBF), the mechanism defined in BIP 125 that allows an unconfirmed transaction to be replaced by a higher-fee version. BIP 125 was deployed in Bitcoin Core 0.12.0 in February 2016 and introduced five rules that a replacement must satisfy. Three of these rules create exploitable attack surfaces.

The Five BIP 125 Rules

Rules 1, 3, and 5 are the primary attack surfaces. Each creates a distinct pinning variant with different mechanics and costs.

Rule 3 Pinning: The Absolute Fee Attack

Rule 3 pinning is the most commonly exploited variant. The core insight: BIP 125 requires a replacement to pay a higher absolute fee (total satoshis), not just a higher feerate (satoshis per virtual byte). An attacker can exploit this gap by attaching a large, low-feerate child transaction to the victim's transaction.

Attack Scenario

Consider a shared transaction (such as a Lightning commitment transaction) that Alice and Mallory both have the ability to spend from:

1. The shared transaction txM is 1 kvB and pays 2 sat/vB (2,000 sat total fee)
2. Mallory attaches a child transaction spending her output from txM: approximately 100 kvB at the minimum feerate of 1 sat/vB (100,000 sat total fee)
3. Alice now wants to replace txM via RBF. Rule 3 requires her replacement to pay at least 2,000 + 100,000 = 102,000 sat in absolute fees
4. For Alice's replacement of ~1 kvB, this means paying an effective feerate of ~102 sat/vB just to overcome Mallory's low-feerate child

Asymmetric cost: Mallory pays roughly 100,000 sat for her pinning child (which she can send to herself, recovering the funds if it confirms). Alice must pay 102,000+ sat just to replace a 1 kvB transaction. With Bitcoin Core's default descendant size limit of 101 kvB, the Bitcoin Optech documentation notes the attacker can force the victim to pay a minimum of 0.001 BTC or more in fee bumps.

Rule 5 Pinning: Exhausting the Descendant Limit

Bitcoin Core enforces a default limit of 25 in-mempool descendants per transaction (and a total descendant size of 101 kvB). Rule 5 caps the total number of transactions that can be evicted by a single replacement at 100. Attackers exploit both limits.

Descendant Chain Attack

In this variant, the attacker fills the 25-descendant limit with their own low-fee child transactions:

1. The shared transaction txM has outputs spendable by both Alice and Mallory
2. Mallory creates a chain of 24 descendant transactions from her output, each at the minimum feerate
3. Alice cannot attach a CPFP child because the descendant limit is already exhausted
4. Alice also cannot RBF-replace the parent because Rule 3 forces her to pay for all of Mallory's descendants, and if Mallory crafts enough conflicts, the eviction count exceeds Rule 5's 100-transaction limit

The result: Alice's transaction is effectively frozen in the mempool, unable to be confirmed at a competitive feerate or replaced at a reasonable cost.

Opt-in RBF Pinning

Before full RBF became the default policy, BIP 125 Rule 1 required transactions to explicitly signal replaceability by setting an input's nSequence value below 0xFFFFFFFE. An attacker in a multiparty protocol could craft a transaction that does not signal RBF, preventing the other parties from replacing it entirely.

This was particularly dangerous in protocols where one party controls the initial broadcast: they could publish a non-signaling version that other participants cannot replace, regardless of how high a fee they are willing to pay. Peter Todd documented extensively how full RBF makes denial-of-service attacks on multiparty protocols significantly more expensive.

Why Lightning Is the Primary Target

The Lightning Network is the protocol most affected by transaction pinning because its security model depends on timely on-chain confirmation. Lightning channels use commitment transactions and HTLCs with timelocks: if a commitment transaction cannot confirm before a timelock expires, a counterparty can steal funds.

Commitment Transaction Pinning

When a Lightning channel force-closes, one party broadcasts a commitment transaction. The other party may need to broadcast their own version (or a justice transaction if the broadcast version is revoked). Transaction pinning can prevent the honest party's version from confirming:

• The attacker broadcasts a low-feerate commitment transaction with a large, low-fee child attached (Rule 3 pinning)
• The victim cannot efficiently replace it because the absolute fee threshold is inflated
• Meanwhile, HTLC timelocks are counting down, and the attacker can claim HTLC outputs once the timelocks expire

HTLC Preimage Pinning

A more sophisticated variant targets individual HTLCs. As documented by Bastien Teinturier, the attacker can create a mempool split where miners see a preimage-revealing success transaction (at a low feerate, too low to confirm), while non-mining nodes see the timeout transaction. The victim cannot learn the preimage from the network and eventually loses the HTLC when the upstream timeout expires.

No global mempool: Bitcoin does not have a single, canonical mempool. Each node maintains its own version based on what transactions it has received. An attacker can exploit this by broadcasting different transaction versions to different parts of the network, ensuring miners see one version while victims see another.

Impact Beyond Lightning

Any Bitcoin protocol that relies on timely transaction confirmation is vulnerable to pinning. The severity depends on how time-sensitive the protocol's on-chain interactions are.

Discreet Log Contracts

Discreet Log Contracts (DLCs) use timelocked refund transactions that become valid after a contract's expiration period. If a counterparty can pin the settlement transaction after the oracle attests, the refund timelock may expire first, causing an incorrect settlement. DLCs face the same fundamental challenge as Lightning: any protocol that uses pre-signed transactions with timelocks is vulnerable when an adversary can manipulate mempool state to delay confirmation.

Vault Constructions

Bitcoin vaults use timelocked recovery transactions that allow owners to claw back funds during a waiting period. If a thief can pin the recovery transaction until the timelock expires, the stolen funds become permanently unrecoverable.

Atomic Swaps and Coinjoins

Atomic swaps and CoinJoin transactions involve multiple parties contributing inputs. Any participant can pin the shared transaction by broadcasting a conflicting spend of their input with a large, low-feerate child attached, preventing other participants from completing the protocol.

The Defense Timeline: From Carve-Outs to Cluster Mempool

Fixing transaction pinning has been one of Bitcoin Core's longest ongoing efforts. The challenge: every defense must preserve the mempool's DoS resistance while making fee bumping work reliably for honest users. The solutions have arrived in stages, each addressing different aspects of the problem.

CPFP Carve-Out (2019)

The first targeted fix, proposed by Matt Corallo in November 2018 and shipped in Bitcoin Core 0.19. The carve-out allowed one additional child transaction beyond the 25-descendant limit, provided the child had exactly one unconfirmed ancestor and was no larger than 10 kvB. This gave the second party in a two-party contract (such as a Lightning channel) the ability to CPFP fee-bump even after the first party filled the descendant limit.

The carve-out was a pragmatic stopgap: it only worked for two-party protocols and did not address Rule 3 pinning at all.

Anchor Outputs in Lightning (2020)

The Lightning specification (BOLT 3) was updated to add anchor outputs to commitment transactions. Each party gets a dedicated output they can spend to attach a CPFP child, enabling independent fee bumping. Anchor outputs also locked each anchor to the respective party's funding key to prevent the counterparty from attaching pinning children to the wrong anchor.

Anchor outputs improved the situation but did not eliminate pinning. An attacker could still pin HTLC-spending transactions, and the CPFP carve-out's limitations meant the fix was incomplete for protocols with more than two parties.

Full RBF (2024)

Bitcoin Core 28.0, released on October 2, 2024, changed the default value of -mempoolfullrbf from 0 to 1. This eliminated opt-in RBF pinning: all transactions became replaceable regardless of their nSequence signaling. Bitcoin Core 29.0, released on April 14, 2025, removed the option entirely, making full RBF unconditional.

TRUC Transactions: BIP 431 (2024)

TRUC (Topologically Restricted Until Confirmation) transactions, authored by Gloria Zhao and defined in BIP 431, introduced strict topology limits for transactions using nVersion=3. Shipped in Bitcoin Core 28.0, TRUC transactions enforce the following constraints:

TRUC transactions directly neutralize Rule 3 pinning: with the child capped at 1,000 vB, the maximum absolute fee an attacker can force onto a replacement drops from over 100,000 sat (with a 100 kvB pinning child) to roughly 1,000 sat. Rule 5 pinning is eliminated because only one descendant is allowed, so the eviction count never exceeds 2 transactions.

TRUC also introduces sibling eviction: if a new child would exceed the one-descendant limit, Bitcoin Core evaluates whether to evict the existing child using standard RBF rules. This means the honest party can always replace the attacker's child with a higher-fee version.

Pay-to-Anchor Outputs (2024)

Shipped alongside TRUC in Bitcoin Core 28.0, Pay-to-Anchor (P2A) outputs use the script OP_1 <4e73> to create keyless anchor outputs. Unlike traditional anchor outputs that require a specific key to spend, P2A outputs can be spent by anyone, enabling third-party fee bumping. The P2A output requires no witness data, making it more compact than the OP_TRUE anchors used previously.

One-Parent-One-Child Package Relay (2024)

Also in Bitcoin Core 28.0, 1P1C package relay allows a low-feerate parent transaction to be relayed together with a high-fee child as a single package. Before package relay, a zero-fee TRUC parent would be rejected by each individual node because it fell below the minimum relay fee, even though the child would make the package economically rational. 1P1C relay solves this by evaluating the parent-child pair as a unit.

Ephemeral Dust (2025)

Bitcoin Core 29.0 (April 2025) added support for ephemeral dust: a mechanism allowing zero-value or below-dust outputs in TRUC transactions, provided those outputs are immediately spent by a child in the same package. This enables Lightning commitment transactions to include a zero-value anchor output without violating the dust policy, further reducing the on-chain footprint of fee-bumping anchors.

Cluster Mempool (2026)

The most fundamental reform, designed by Suhas Daftuar and Pieter Wuille. Cluster mempool replaces the per-transaction ancestor and descendant limits with a cluster-based model where related transactions are grouped into clusters (up to 64 transactions or 101 kvB) and linearized by feerate. Cluster mempool shipped in Bitcoin Core 31.0, released in April 2026, bringing this architectural overhaul to the broader network.

Cluster mempool introduces a new RBF rule: replacements are only accepted if the resulting mempool's feerate diagram is strictly better than before the replacement. This eliminates all known cases where a replacement makes the mempool worse off for miners, closing the economic misalignment that pinning attacks exploit. It also removes the CPFP carve-out in favor of TRUC transactions and sibling eviction.

Defense Deployment Summary

Lightning's Adoption of Pinning Defenses

The Lightning specification has been evolving alongside Bitcoin Core's mempool policy changes. BOLT specification PR #1228, merged in May 2026, specifies zero-fee commitment transactions using TRUC (v3), where commitment transactions pay no fee and rely entirely on a P2A anchor output and CPFP child for fee determination at broadcast time. This design eliminates the need for the update_fee mechanism (which was itself a pinning risk, as the fee-setting party could intentionally underpay) and leverages TRUC's topology restrictions to prevent all known pinning vectors against commitment transactions.

However, HTLC-spending transactions remain more complex. V3 transactions and package relay significantly reduce the attack surface, but the fundamental challenge of mempool partitioning (where an attacker shows different transaction versions to different parts of the network) persists as long as Bitcoin lacks a consensus-enforced global mempool.

Remaining Open Problems

Even with TRUC, package relay, and cluster mempool, some pinning-adjacent problems remain:

• Mempool partitioning: attackers can broadcast different transaction versions to miners vs. non-miners, a fundamental limitation of Bitcoin's peer-to-peer relay
• Multi-party protocols: TRUC's one-parent-one-child topology works well for two-party channels but does not extend easily to protocols with three or more participants
• Fee estimation under adversarial conditions: even with reliable fee bumping, predicting the fee needed to confirm within a timelock window remains difficult during mempool congestion
• HTLC-level pinning: while commitment transaction pinning is largely solved by TRUC, individual HTLC resolution transactions face ongoing challenges when attackers control the preimage

Alternative Architectures: Avoiding the Mempool Entirely

The pinning problem is fundamentally tied to the mempool: any protocol that requires broadcasting transactions and waiting for confirmation is exposed. Some Bitcoin Layer 2 designs sidestep this by minimizing or eliminating on-chain interaction during normal operation.

Spark, for example, uses a statechain model where transfers happen through cryptographic key rotation rather than on-chain transactions. Funds move by updating who holds the signing authority over a UTXO, with no transaction broadcast required. This means there is no mempool interaction during normal transfers and therefore no surface for pinning attacks. Users retain the ability to exit to Bitcoin L1 unilaterally via pre-signed transactions, but the exit path uses a timelock hierarchy (current owners have the shortest timelocks) rather than the penalty-based mechanism that makes Lightning commitment transactions vulnerable to pinning.

This is not a free lunch: Spark introduces a different trust assumption (1-of-n operator honesty during transfers). But it demonstrates that the pinning problem is architecture-dependent, not an inherent cost of scaling Bitcoin.

What This Means for Developers

If you are building on Bitcoin and your protocol uses pre-signed transactions, timelocks, or multiparty coordination, transaction pinning should be part of your threat model. Practical guidance:

• Use TRUC (nVersion=3) for any time-sensitive pre-signed transactions to enforce strict topology limits and enable reliable replacement
• Use P2A anchor outputs instead of keyed anchors for fee bumping to reduce size and enable third-party fee contribution
• Design for package relay: structure transactions as parent-child pairs where the parent can be zero-fee and the child provides the fee at broadcast time
• Avoid protocols that depend on specific mempool state: assume the attacker can show different transaction versions to different nodes
• Test against Bitcoin Core 28.0+ policies: the Bitcoin Optech wallet integration guide provides detailed implementation guidance for TRUC and package relay

For developers building on higher-level infrastructure, the Spark SDK abstracts away mempool concerns entirely, enabling instant Bitcoin and stablecoin transfers without direct exposure to L1 relay policy. For a deeper understanding of Bitcoin's fee market dynamics, see our research on fee market dynamics.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.