lightning-network bitcoin-core mempool security

Transaction Pinning Attacks: The Mempool Vulnerability That Threatens Lightning

Bitcoin Index · · 8 min read
Transaction Pinning Attacks: The Mempool Vulnerability That Threatens Lightning

Transaction pinning sounds like a niche technical quirk, but it’s one of the most serious security challenges facing Lightning Network. The attack exploits Bitcoin’s mempool policies to prevent legitimate transactions from confirming, potentially allowing attackers to steal funds from routing nodes.

The good news: after years of development, Bitcoin Core 28.0 (released October 2024) deployed v3 transactions, a solution that makes pinning attacks vastly harder to execute. But the vulnerability still matters, both for understanding Lightning’s security assumptions and for appreciating why Bitcoin’s mempool rules are so carefully designed.

What is transaction pinning?

Transaction pinning is a mempool policy exploit that prevents fee bumping. According to Bitcoin Optech, it’s “a method for making fee bumping prohibitively expensive by abusing node protections against attacks that can waste bandwidth, CPU, and memory.”

The vulnerability exists because mempool policies designed to protect nodes from resource exhaustion can be weaponized when multiple parties share control over a transaction. An attacker leverages these protections to block their counterparty from getting a transaction confirmed, even if the counterparty is willing to pay high fees.

Developer Gloria Zhao defines it succinctly: “A pinning attack is a type of censorship in which the attacker takes advantage of mempool policy to prevent a transaction from confirming.”

How pinning works: Three attack vectors

Bitcoin Core uses Replace-by-Fee (RBF) rules and package limits to prevent denial-of-service attacks on the network. These same protections create pinning opportunities.

RBF rule 3: Absolute fee exploitation

BIP 125 Rule 3 requires that a replacement transaction pay a higher absolute fee than the sum of all transactions it replaces, including descendants. This creates an obvious attack: attach a massive low-feerate child transaction to the transaction you want to pin.

Attack scenario: Alice broadcasts transaction A. Mallory attaches a 100,000 vbyte child transaction with a 1 sat/vbyte feerate to A. Now Alice must pay to replace not just A, but the entire package. Even if Alice only wants to bump A by 10 sats/vbyte, she might need to pay 0.001 BTC or more in absolute fees just to cover Mallory’s junk child transaction.

Package limit pinning: monopolizing descendants

Bitcoin Core limits transactions to 25 descendants and 101,000 vbytes of descendant size. BIP 431 explains: “When a transaction has multiple outputs owned by different parties, a malicious party can prevent the other(s) from CPFPing their transaction by attaching enough descendants to monopolize the descendant limit.”

An attacker can completely block Child-Pays-For-Parent (CPFP) fee bumping by creating 25 descendant transactions, exhausting the limit before an honest party can add their own fee-bumping child.

RBF rule 5: The 100-transaction conflict wall

RBF rules prevent replacing more than 100 transactions at once (to avoid forcing nodes to revalidate enormous transaction sets). An attacker can attach enough descendants to make replacement impossible regardless of fees paid.

Why Lightning is vulnerable

Lightning Network’s security model assumes parties can reliably get time-sensitive transactions confirmed on-chain within specific timeframes. Transaction pinning breaks this assumption.

Lightning channels use pre-signed commitment transactions with Hash Time-Locked Contracts (HTLCs) that have strict expiration deadlines. If an honest party can’t get their HTLC transaction confirmed before the timelock expires, an attacker can steal funds.

Developer t-bast documents the attack: “The goal of both of these attacks is to steal pending HTLCs (HTLC outputs in the broadcast commitment transaction), exploiting a routing node by timing out HTLCs upstream while collecting them on-chain downstream.”

Attack flow:

  1. Alice routes a payment through Bob to Carol
  2. Bob force-closes his channel with Carol by broadcasting a commitment transaction
  3. Carol and Alice collude to pin Bob’s HTLC-timeout transaction in the mempool
  4. Alice times out Bob’s HTLC upstream (Bob loses funds to Alice)
  5. Carol claims the HTLC on-chain downstream (Bob pays Carol)
  6. Result: Bob pays twice for the same HTLC

The mempool split-brain problem

Because there’s no global mempool (famously: “There Ain’t No Such Thing As A Global Mempool”), attackers can create mempool partitions. T-bast explains: “A clever and well-funded attacker is able to manipulate mempools and create arbitrary split-brains, that last an arbitrary amount of time.”

An attacker can ensure miners see a low-fee pinned transaction while the victim’s higher-fee replacement circulates only among non-mining nodes, never reaching miners’ mempools.

The evolution of mitigations

CPFP carve-out (limited, being phased out)

CPFP carve-out was the first deployed mitigation, implemented in Bitcoin Core 0.19 (2019). Bitcoin Optech describes it: “CPFP carve out is a transaction relay policy implemented in Bitcoin Core that allows a single transaction to moderately exceed the node’s maximum package size and depth limits if that transaction only has one unconfirmed ancestor.”

This allowed Lightning to use two anchor outputs (one for each party), ensuring both could CPFP fee-bump even if their counterparty had already used the descendant limit.

But CPFP carve-out only works for exactly two parties, doesn’t address RBF Rule 3 pinning, and is incompatible with cluster mempool (a planned Bitcoin Core improvement). BIP 431 states plainly: “Cluster Mempool necessitates the removal of CPFP Carve Out.”

Package relay (infrastructure)

Package relay allows nodes to evaluate groups of related transactions together, using the package’s combined feerate rather than individual transaction feerates. Bitcoin Optech explains: “Package relay is a proposed feature for Bitcoin relay nodes that would allow them to send and receive packages of related transactions which would be accepted or rejected based on the feerate of the overall package.”

This is critical infrastructure for anti-pinning solutions. Without package relay, a zero-fee parent transaction is rejected before nodes even see the fee-bumping child. Lightning commitment transactions signed months in advance with outdated feerates would simply fail to propagate.

Bitcoin Core 28.0 (October 2024) implemented limited 1-parent-1-child (1p1c) package relay, enabling parent transactions below minimum relay feerate when packaged with a fee-bumping child.

v3 transactions (the current solution)

Version 3 transactions, formally called “Topologically Restricted Until Confirmation” (TRUC), were standardized in BIP 431 and made available in Bitcoin Core 28.0.

The Bitcoin Core 28.0 release notes state: “Transactions with version number set to 3 are now treated as standard on all networks (#29496), subject to opt-in Topologically Restricted Until Confirmation (TRUC) transaction policy as described in BIP 431.”

Transactions with nVersion=3 opt into special topology restrictions:

  1. Always replaceable (signals RBF regardless of BIP 125 signaling)
  2. Limited topology (maximum 1 unconfirmed ancestor, 1 unconfirmed descendant)
  3. Size limits (parent max 10,000 vbytes, child max 1,000 vbytes)
  4. Inheritance (all ancestors and descendants must also be v3)
  5. Zero-fee allowed (can be below minimum relay fee when in a package)

The 1-parent-1-child topology makes pinning vastly harder. BIP 431 explains: “A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000 vB.”

Limiting child size to 1,000 vbytes caps the absolute fee required for replacement. At 1 sat/vbyte, the maximum additional cost is only 1,000 sats, a 100x improvement over the prior 100,000 vbyte limit.

With only 1 descendant allowed, an attacker cannot monopolize the descendant limit. And Bitcoin Core implements sibling eviction for TRUC: if a new child would exceed the 1-descendant limit, the existing child can be evicted using RBF rules.

Bitcoin Core also enabled package RBF for TRUC transactions, allowing conflicting v3 transactions to replace each other when packaged with fee-bumping children, even if the parents themselves have identical fees. This allows Lightning commitment transactions to be signed with zero fees and replaced by whichever party broadcasts first.

The 2023 replacement cycling attack

In October 2023, developer Antoine Riard disclosed a new pinning variant: replacement cycling attacks. Bitcoin Magazine covered it as “the replacement cycle attack against HTLCs creating pinning-like problems.”

Attack mechanism:

  1. Bob broadcasts his commitment transaction with an HTLC-timeout
  2. Mallory broadcasts an HTLC-preimage transaction with higher fees, replacing Bob’s timeout via RBF
  3. Mallory then broadcasts an unrelated transaction to evict the preimage transaction
  4. Repeat the cycle to delay Bob’s timeout until Alice can claim upstream

The attack exploited the fact that HTLC transactions use SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, allowing Mallory to add inputs and manipulate which transaction remains in the mempool.

V3 transactions with package RBF reduce (but don’t eliminate) this attack surface. Full mitigation requires additional changes to HTLC construction or continued relay policy improvements.

Looking ahead: Ephemeral anchors and cluster mempool

Ephemeral anchors build on v3 transactions to further improve fee-bumping. Bitcoin Optech describes them: “A v3 transaction containing as little as zero fee that has a zero-value output paying OP_TRUE as the entire script would be accepted when included in a relay package with a fee-paying child.”

Advantages include anyone-can-spend anchors (no need for specific party signatures), zero-value outputs (eliminating capital inefficiency of 330-sat anchor outputs), and single-anchor designs (combined with package RBF, only one anchor needed).

Bitcoin Core enabled ephemeral dust outputs in version 28.1 (November 2024) and introduced Pay-to-Anchor (P2A) as a standard output type in 28.0 (August 2024). Lightning implementations are actively working on integrating v3 transactions with ephemeral anchors.

Cluster mempool is a fundamental mempool restructuring planned for Bitcoin Core. BIP 431 explains: “Cluster Mempool makes fundamental changes to mempool structure and policy rules, enabling the accurate assessment of the incentive compatibility of accepting or removing a transaction, among other things.”

Cluster mempool will enable precise incentive compatibility calculations, support more complex transaction topologies than v3, require removal of CPFP carve-out (replaced by v3/TRUC), and allow deployment of additional anti-pinning improvements.

Current deployment status

Bitcoin Core:

  • v3 transactions: live on mainnet (since 28.0, October 2024)
  • 1p1c package relay: live on mainnet (since 28.0)
  • Package RBF for v3: live on mainnet (since 28.0)
  • Pay-to-Anchor (P2A): standard (since 28.0)
  • Ephemeral dust: standard (since 28.1, November 2024)

Lightning Network:

The transition path is clear: CPFP carve-out → v3/TRUC → cluster mempool → enhanced anti-pinning policies.

Key takeaways

  1. Pinning is a mempool policy exploit, not a consensus-level attack
  2. Lightning is vulnerable because pre-signed time-sensitive transactions can be censored
  3. CPFP carve-out was a stopgap that helped but is being phased out
  4. V3 transactions (TRUC) are the current solution, live on mainnet since October 2024
  5. Package relay is critical infrastructure that enables v3’s anti-pinning properties
  6. Ephemeral anchors are the next evolution, already partially deployed
  7. Cluster mempool is the long-term foundation for comprehensive pinning resistance

Transaction pinning remains an active area of development, with solutions being deployed incrementally to maintain backward compatibility while improving security for Lightning and other Layer 2 protocols.

Sources

Data as of March 14, 2026.