Pay-to-Anchor and V3 Transactions: Bitcoin's New Fee-Bumping Toolkit

Fee bumping is one of the hardest operational problems in Bitcoin. When a transaction is stuck in the mempool during a fee spike, the sender needs a reliable way to increase its priority. For single-party transactions, this is inconvenient. For multi-party protocols like Lightning channels, it is a security issue: the inability to confirm a time-sensitive commitment transaction can result in lost funds.

Two changes shipped in Bitcoin Core 28.0 (October 2024) form a new foundation for fee bumping: v3 (TRUC) transactions, which restrict transaction topology to prevent pinning, and Pay-to-Anchor (P2A) outputs, which create a purpose-built, anyone-can-spend output for CPFP fee bumping. Together with ephemeral dust support added in Bitcoin Core 29.0, these tools replace years of fragile workarounds with a clean, composable design.

The Transaction Pinning Problem

Transaction pinning is a class of attacks where a malicious party prevents a legitimate transaction from being fee-bumped or confirmed. Pinning exploits the gap between Bitcoin's consensus rules (what miners will include in a block) and mempool relay policy (what nodes will propagate). A transaction can be valid for inclusion in a block yet impossible to relay because policy rules reject it.

In multi-party protocols, pinning becomes dangerous. Consider a Lightning channel force close: both parties hold a copy of the commitment transaction, and either can broadcast it. If one party broadcasts and then attaches a large, low-feerate child transaction to their anchor output, the honest party may be unable to fee-bump the commitment. The mempool's descendant limits prevent additional children, and Replace-by-Fee (RBF) requires paying for the total fee of the package being replaced, which the attacker can make arbitrarily expensive.

Why pinning matters: In a Lightning channel, a commitment transaction that cannot confirm within the timelock window can allow a counterparty to steal funds via an outdated state. Pinning turns mempool policy into a weapon against honest participants.

Early mitigations and their limits

Bitcoin Core 0.19 introduced the CPFP carve-out: a special exception allowing one extra small child transaction (up to 10,000 vB) past the normal descendant limit, as long as the child has exactly one unconfirmed ancestor. This was designed specifically for Lightning's two-party commitment transactions, giving each party one guaranteed slot to attach a fee-bumping child.

The carve-out solved the immediate problem but introduced new constraints. It only works for two-party protocols. It does not scale to constructions with three or more participants, such as channel factories or coinpools. It also cannot prevent a counterparty from attaching a moderately large, low-feerate child that is expensive to replace. The carve-out was a patch, not a solution.

What Are V3 (TRUC) Transactions?

BIP 431 defines Topologically Restricted Until Confirmation (TRUC) transactions, commonly called v3 transactions because they set the transaction version field to 3. Proposed by Gloria Zhao, TRUC transactions opt into strict topology rules enforced by mempool policy (not consensus). These rules make fee bumping predictable and pinning-resistant.

The topology rules

TRUC transactions enforce a 1-parent-1-child topology while any transaction in the cluster remains unconfirmed:

• A TRUC transaction may have at most one unconfirmed ancestor (its parent).
• A TRUC transaction may have at most one unconfirmed descendant (its child).
• Unconfirmed ancestors of a TRUC transaction must also be TRUC.
• The parent transaction is limited to 10,000 virtual bytes (vB).
• A child with an unconfirmed TRUC parent is limited to 1,000 vB.

These limits produce a maximum unconfirmed cluster size of two transactions. This bounded cluster makes it straightforward to evaluate whether a replacement is more incentive-compatible than what it replaces, enabling package RBF and sibling eviction.

Sibling eviction

If a TRUC parent already has one unconfirmed child and a new, higher-fee child arrives, the node evicts the existing child and accepts the replacement. This is called sibling eviction (implemented in Bitcoin Core PR #29306). Because the child is capped at 1,000 vB, the maximum cost to replace an attacker's pinning child drops from potentially hundreds of thousands of satoshis to roughly 1,000 satoshis: the fee of a 1,000 vB transaction at prevailing rates.

Policy, not consensus: TRUC rules are enforced by mempool policy, not by consensus. A miner could include a block with a TRUC parent having multiple children, and the block would be valid. The protection works because standard relay nodes refuse to propagate topology-violating transactions, making them unlikely to reach miners in the first place.

Key Bitcoin Core PRs for TRUC

How Pay-to-Anchor (P2A) Works

BIP 433, authored by Gregory Sanders, defines the Pay-to-Anchor output type. A P2A output is a SegWit v1 output with a two-byte witness program (0x4e73), producing the scriptPubKey OP_1 <0x4e73>. The two bytes were chosen so the resulting bech32m address on mainnet reads bc1pfeessrawgf, spelling out "fees" as a mnemonic.

The output is anyone-can-spend: no signature, key, or witness data is required to spend it. This is a deliberate design choice. The P2A output exists solely to be consumed by a CPFP child transaction that brings enough fee to confirm the parent. Because anyone can spend it, any party in a multi-party protocol (or even a third-party fee bumping service) can attach the fee-bumping child.

P2A spending rules

Bitcoin Core treats P2A inputs as standard for spending only when no witness data is provided. Consensus itself is unaffected: any witness would be valid at the consensus level, but policy requires an empty witness stack. This keeps spending transactions small and predictable.

The dust threshold for P2A is 240 satoshis, lower than the 330-satoshi threshold for P2WSH outputs used by the old anchor output design. A P2A output carrying 240 satoshis costs roughly 65 vB of output space, smaller than the keyed scripts it replaces.

Standardization timeline

P2A spending was made standard in Bitcoin Core 28.0 (October 2024) via PR #30352. The BIP itself (BIP 433) is informational and was assigned its number after the code had already shipped: the implementation preceded the formal specification. Propagation of P2A spends depends on network adoption of Core 28.0 and later versions.

Ephemeral Dust and Zero-Value Anchors

Even with P2A, the 240-satoshi dust threshold means every commitment transaction must lock a small amount in the anchor output. Over millions of channels, this adds up. The ephemeral dust policy, shipped in Bitcoin Core 29.0 via PR #30239, eliminates this cost.

Under the ephemeral dust rule, a transaction may contain a single dust output (including a zero-value output) as long as the transaction itself pays zero fees. To spend any unconfirmed output from this transaction, the spender must also spend the dust output, ensuring the dust never persists in the UTXO set.

Combined with P2A, this enables a clean pattern: a commitment transaction pays zero fees and includes a single zero-value P2A output. Whoever needs the transaction confirmed creates a child that spends the P2A output and pays the entire fee for the package. The anchor contributes zero satoshis to the UTXO set and costs nothing to create.

1P1C Package Relay

None of this works without package relay: the ability for nodes to evaluate a parent and child together when deciding whether to accept them into the mempool. Bitcoin Core 28.0 implemented a limited form called 1P1C (1 parent, 1 child) relay: a parent transaction that is below the dynamic mempool minimum feerate can enter the mempool if it arrives alongside a child that pays enough fee for both.

For TRUC transactions specifically, the parent can pay zero fees entirely, relying on the child for all fee contribution. This is what makes zero-fee commitment transactions viable: they relay as part of a package, not on their own.

Comparing Pre-P2A and Post-P2A Fee Bumping

The following table summarizes how fee bumping worked before and after the P2A toolkit:

How Lightning Is Adopting P2A

The Lightning specification has been updated to take advantage of the new toolkit. BOLTs PR #1228 defines a new zero-fee commitment format that replaces the legacy two-anchor design:

• Commitment transactions set version 3 (TRUC) and pay zero fees.
• A single shared P2A output replaces the two per-party keyed anchors.
• The update_fee mechanism is removed entirely, eliminating a major source of force closures during fee spikes.
• HTLCs are capped at 114 per party to stay within the 10,000 vB TRUC parent limit.

This represents a significant simplification. Under the old design, Lightning nodes had to estimate future on-chain fees, negotiate them with the counterparty, and maintain a reserve of confirmed UTXOs for emergency fee bumping. Disagreements on fee estimates were a common cause of channel force closures. The zero-fee commitment design eliminates the estimation and negotiation steps entirely.

Old anchors vs new P2A anchors in Lightning

Beyond Lightning: Implications for Bitcoin L2s

The P2A and TRUC toolkit is not specific to Lightning. Any multi-party Bitcoin protocol that uses pre-signed transactions and needs reliable fee bumping benefits from these changes. This includes Ark, eltoo/LN-Symmetry, DLCs, and various coinpool designs.

The key property is composability: because P2A outputs are anyone-can-spend, fee bumping can be delegated to third-party services. A user who does not have a confirmed UTXO available for CPFP can pay a fee-bumping service to do it for them. This is impractical with keyed anchors, where only the key holder (or anyone after a CSV delay) can create the child.

The UTXO management burden

One constraint that P2A does not fully eliminate is the need to maintain confirmed UTXOs for fee bumping. Someone still needs to fund the CPFP child transaction. For Lightning nodes, this means keeping a reserve of on-chain funds available at all times. The improvement is that the reserve is simpler to manage: a single pool of funds can serve all channels, and any UTXO in the wallet can be used (not just specific anchor-matched UTXOs).

Spark and the Fee-Bumping Landscape

Spark takes a fundamentally different approach to the problems that P2A addresses. As a statechain-based protocol, Spark transfers ownership of Bitcoin by rotating key shares between parties rather than creating and broadcasting pre-signed transactions. This means Spark does not rely on on-chain fee bumping for normal operation: transfers happen off-chain without touching the mempool.

Spark users do need on-chain transactions for deposits and unilateral exits, but these are single-party operations without the adversarial dynamics that make fee bumping in Lightning so complex. There is no counterparty racing to pin your exit transaction. This architectural choice eliminates an entire category of operational complexity that P2A and TRUC are designed to mitigate in channel-based protocols.

That said, P2A improvements benefit the broader Bitcoin Layer 2 ecosystem that Spark coexists with. A healthier Lightning Network means better interoperability for Spark users who send and receive Lightning payments through Spark Service Providers. More reliable fee bumping across all L2s reduces the risk of on-chain congestion events that can affect everyone.

Limitations and Open Questions

Network upgrade dependency

P2A and TRUC are relay policy changes, not consensus changes. They only work when a sufficient fraction of network nodes have upgraded to Bitcoin Core 28.0 or later. Until then, P2A-spending transactions may not propagate reliably across the network. As of late 2026, node adoption is progressing but not universal.

HTLC count reduction

The 10,000 vB TRUC parent limit forces Lightning to cap HTLCs at 114 per party (down from 483 under the old design). For most channels this is not a practical constraint, but high-throughput routing nodes may notice the reduction. This is an intentional tradeoff: smaller transactions are easier to replace, which is the whole point of the pinning defense.

Policy vs consensus gap

Because TRUC rules are policy-only, a miner who builds custom block templates could include topology-violating transactions. This is unlikely in practice (miners generally run standard software) but remains a theoretical concern. A disclosed vulnerability (CVE-2025-62861) showed that blockchain reorganizations can restore topology states that the mempool would not accept, temporarily halting block template creation in affected versions.

Looking Ahead

P2A and TRUC are foundational pieces. Future improvements will build on them: full package relay beyond 1P1C, broader cluster mempool redesigns, and potential consensus changes like OP_CTV or SIGHASH_ANYPREVOUT that could simplify fee bumping further.

For developers building on Bitcoin, these tools represent a meaningful step forward. The fee-bumping problem is not fully solved, but the design space has improved dramatically. Protocols that previously needed custom workarounds for pinning can now rely on standardized, composable primitives.

Developers interested in how different Layer 2 designs handle fee bumping and on-chain settlement can explore the Spark documentation for a statechain-based approach, or dive deeper into v3 transactions and package relay in Lightning for the channel-based perspective.

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.