Transaction Pinning

What Is Transaction Pinning?

Transaction pinning is a class of censorship attacks in which an adversary exploits Bitcoin node mempool relay policies and anti-DoS protections to make fee bumping prohibitively expensive or impossible. The goal is to prevent a target transaction from confirming in a timely manner. This is particularly dangerous for multiparty protocols like Lightning, where the security model depends on broadcasting and confirming transactions before timelocks expire.

The fundamental vulnerability arises whenever a transaction is not entirely controlled by a single party. In a standard single-user wallet, you can always replace or fee-bump your own transactions. But in protocols like Lightning, both channel counterparties hold valid commitment transactions they can broadcast. A malicious counterparty can craft their broadcast to exploit relay policy rules, blocking the honest party from responding with appropriate fees.

How It Works

Transaction pinning exploits the rules that Bitcoin Core uses to manage its mempool: the policies governing transaction replacement (BIP 125) and descendant package limits. These rules exist for good reason (preventing DoS attacks on nodes), but they create openings for adversaries in multiparty settings. There are several distinct pinning variants.

BIP 125 Rule 3 Pinning

BIP 125 Rule 3 requires that a replacement transaction pay an absolute fee at least as high as the sum of fees paid by all transactions it would evict from the mempool. An attacker exploits this by attaching a large, low-feerate descendant to the transaction they want to pin.

For example, the attacker broadcasts a commitment transaction and then spends one of its outputs with a child transaction that is nearly 100,000 vbytes but pays only 1 sat/vbyte. Despite its low feerate, this child accumulates roughly 0.001 BTC in absolute fees due to its sheer size. Any honest party attempting to replace the pinned transaction via RBF must now pay more than that amount in total fees, even if their replacement is tiny and high-feerate:

# Attacker's pinning setup
Commitment TX (250 vB, 5 sat/vB)     → 1,250 sats fee
  └─ Blocker child (99,000 vB, 1 sat/vB) → 99,000 sats fee

# Honest party must beat total: 100,250 sats
# For a 250 vB replacement, that means ~401 sat/vB minimum
# The attacker's cost is near zero (low-feerate child won't confirm)

The attacker pays almost nothing because their low-feerate child is unlikely to confirm and can be reused. The honest party faces an inflated fee requirement that may be impractical during high-fee environments.

BIP 125 Rule 5 Pinning

BIP 125 Rule 5 states that a replacement transaction cannot evict more than 100 transactions from the mempool. An attacker exploits this by attaching a chain of descendant transactions to the target. Once the descendant count approaches 100, no RBF replacement is accepted because it would require evicting too many transactions.

This variant also interacts with CPFP package limits. Bitcoin Core enforces a default 25-transaction descendant limit per package. An attacker can attach 24 descendants to a commitment transaction output, completely filling the package. The honest party cannot add a CPFP child because the limit is already reached.

Time-Based Pinning

Even without exploiting specific RBF rules, an attacker can broadcast a version of a commitment transaction with a feerate that is high enough to remain in the mempool but too low to confirm before critical timelocks expire. If the honest party cannot replace it (due to the pinning variants above), they are stuck waiting while HTLC timelocks count down. This is especially effective during fee spikes when many transactions compete for block space.

Why It Threatens Lightning Security

Lightning Network security depends on the ability to confirm commitment transactions and HTLC-claiming transactions before timelocks expire. During a force-close, a party broadcasts the latest commitment transaction to settle the channel on-chain. If an adversary can delay this confirmation past the HTLC timeout, they can steal funds. This is why transaction pinning is considered one of the most serious threats to Lightning channel security.

HTLC Theft Scenario

Consider a routing node forwarding a payment. The node holds HTLCs in two directions: one incoming from Alice and one outgoing to Bob. Bob (the attacker) knows the HTLC preimage but delays revealing it. Instead, Bob pins the commitment transaction at a low feerate so it does not confirm:

1. Bob broadcasts a commitment transaction version crafted for pinning
2. The honest routing node cannot fee-bump or replace it due to relay policy rules
3. The upstream HTLC (from Alice) times out, and Alice reclaims her funds
4. Bob eventually claims the downstream HTLC using the preimage once the pinned transaction confirms
5. The routing node loses the payment amount in both directions

This attack works because the routing node's ability to claim the HTLC depends on getting a transaction confirmed within a deadline. The commitment transaction's fee was set at signing time and may be insufficient when broadcast. For a deeper look at how fees interact with Lightning security, see Bitcoin Fee Market Dynamics.

Pre-Signed Fee Problem

Before anchor outputs, commitment transactions had fixed fees baked in at signing time. The update_fee mechanism let parties renegotiate fees while the channel was open, but it could not predict future fee spikes. If the fee market changed dramatically between signing and broadcast, the commitment transaction might be too cheap to confirm or too expensive (overpaying). This rigidity made pinning attacks straightforward: the attacker simply needed to ensure the pre-signed fee was inadequate.

Mitigations

Anchor Outputs

Anchor outputs add two small outputs to each commitment transaction, one per channel party. Their sole purpose is to serve as inputs for CPFP fee-bumping child transactions. Combined with the CPFP carve-out rule (which allows one extra descendant beyond the package limit for two-party protocols), anchor outputs let each party independently fee-bump the commitment transaction at broadcast time rather than at signing time.

All other commitment transaction outputs are locked with a 1-block CSV (CheckSequenceVerify) delay, ensuring only anchor outputs can be spent for fee bumping before confirmation. Anchor outputs have been deployed across all major Lightning implementations since 2021-2022.

Limitations: anchor outputs require each node to maintain a reserve of confirmed UTXOs for fee bumping. They add on-chain weight. And they do not fully eliminate pinning: an attacker can still chain descendants off their own anchor to create pinning pressure against the carve-out mechanism.

TRUC Transactions (BIP 431)

TRUC (Topologically Restricted Until Confirmation) transactions, signaled by setting nVersion=3, opt into a stricter set of relay policies designed to eliminate pinning. The key rules:

• All TRUC transactions are mandatory replaceable regardless of BIP 125 signaling
• A strict 1-parent-1-child topology is enforced: an unconfirmed TRUC transaction can have at most one unconfirmed ancestor and one unconfirmed descendant, eliminating descendant-count pinning entirely
• Parent transactions are capped at 10,000 vbytes and child transactions at 1,000 vbytes, bounding the absolute fee an attacker can force a victim to pay for replacement
• TRUC transactions can have feerates below the mempool minimum when evaluated as part of a package, enabling zero-fee pre-signed transactions

TRUC transactions became standard in Bitcoin Core 28.0 (October 2024). Wallet-level RPC support was added in 2025. This policy change is the most comprehensive anti-pinning measure deployed to date.

Ephemeral Anchors

Ephemeral anchors extend the anchor output concept by using a zero-value output paying to a standard Pay-to-Anchor (P2A) script. This allows any party to attach a fee-bumping child transaction, not just the channel participants. The zero-value anchor eliminates the need to allocate funds to anchor outputs.

Ephemeral anchors are built on top of TRUC transaction relay. A zero-fee parent transaction containing an ephemeral dust output is accepted into the mempool only as part of a package with a fee-paying child that spends the dust output. This ensures the dust is always cleaned up and the parent gets an appropriate fee at broadcast time. P2A outputs became standard in Bitcoin Core 28.0 (2024), and ephemeral dust became standard in Bitcoin Core 29.0 (April 2025). LDK 0.2 (December 2025) was the first major Lightning implementation to deploy zero-fee commitment channels using this full stack.

Package Relay

Package relay allows Bitcoin nodes to evaluate related transactions as a group based on their aggregate feerate rather than individually. Without it, a parent transaction below the minimum relay feerate is rejected outright, and its fee-bumping child never propagates because the parent is missing.

Bitcoin Core 28.0 introduced 1-parent-1-child (1P1C) package relay, allowing a low-feerate parent and its fee-bumping child to be relayed as a unit. This is essential for making zero-fee commitment transactions viable: the commitment transaction (parent) carries no fee, and the anchor-spending child (child) provides the fee for the entire package. Full arbitrary-depth package relay (BIP 331) remains a proposal.

Current Deployment Status

Risks and Considerations

While recent mitigations have significantly reduced the transaction pinning attack surface, several considerations remain:

• UTXO reserve requirement: anchor output channels require each node to maintain confirmed UTXOs available for fee bumping at all times. Nodes that run out of fee-bumping UTXOs cannot respond to pinning attempts, making UTXO management critical for Lightning operators
• Adoption lag: TRUC transactions and ephemeral anchors require both Bitcoin Core nodes and Lightning implementations to upgrade. Until a supermajority of the network runs updated software, relay of these new transaction types may be unreliable
• Mempool partitioning: since there is no global mempool, a well-funded attacker can ensure miners see one version of a transaction while the broader network sees another. No relay policy change fully solves this problem
• Protocol complexity: each mitigation layer (anchor outputs, TRUC, ephemeral anchors, package relay) adds implementation complexity. Bugs in fee-bumping logic can lead to stuck channels or lost funds, making robust watchtower services and monitoring essential

Layer 2 protocols like Spark take a different approach to channel security. By using a statechain-based architecture with cooperative signing rather than on-chain commitment transactions for routine operations, Spark avoids the fee-bumping challenges that make transaction pinning dangerous in Lightning-style channels.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.