V3 Transactions and Package Relay: Solving Lightning's Fee-Bumping Problem

Lightning Network channels work by exchanging pre-signed commitment transactions that can be broadcast to the Bitcoin blockchain if anything goes wrong. There is a fundamental problem with this design: the fee rate on those transactions is locked in at signing time, which could be hours, days, or months before they actually need to confirm. When fee market conditions change between signing and broadcast, the commitment transaction may be too cheap to enter the mempool, leaving the channel party unable to enforce the latest state on-chain.

V3 transaction policy (formally called TRUC: Topologically Restricted Until Confirmation) and package relay are two complementary changes to Bitcoin Core's mempool rules that solve this problem. Together, they make fee-bumping predictable and resistant to adversarial interference, closing a class of attacks that has threatened Lightning security since the network launched.

Why Pre-Signed Fees Break Under Pressure

Every Lightning channel has two commitment transactions: one for each party. These transactions are signed collaboratively and held off-chain. When Alice and Bob open a channel, they agree on a fee rate for the commitment transaction based on current conditions. As the channel stays open and they route payments, they periodically renegotiate fees using the update_fee message in the Lightning protocol.

This approach has two failure modes. First, fee negotiation is adversarial: a malicious counterparty can refuse reasonable fee updates or propose absurd rates, forcing the honest party into a force close at an unfavorable fee. Second, even with honest negotiation, the agreed fee may be stale by broadcast time. A sudden block space demand spike can render a recently signed commitment transaction unconfirmable.

The natural solution is to sign commitment transactions at a minimal fee and use child-pays-for-parent (CPFP) or replace-by-fee (RBF) to add fees at broadcast time, when actual conditions are known. But before v3 and package relay, both fee-bumping strategies were vulnerable to a category of attack called transaction pinning.

Transaction Pinning: The Attack That Blocked Fee Bumping

Transaction pinning exploits Bitcoin Core's mempool relay rules to prevent a counterparty from fee-bumping a shared transaction. There are two primary variants, and both are relevant to Lightning.

Descendant limit pinning

Before v3, Bitcoin Core limited unconfirmed transaction chains to 25 descendants or 101,000 virtual bytes of total descendant size. In a Lightning commitment transaction, both parties have outputs they can spend. An attacker who broadcasts their version of the commitment transaction can attach up to 24 child and grandchild transactions to their anchor output, filling the descendant limit. When the victim tries to attach their own CPFP child, the node rejects it because the limit has been reached. The commitment transaction is pinned at whatever fee rate it was signed with.

RBF rule 3 pinning

BIP 125 rule 3 requires that a replacement transaction pay a higher absolute fee than the total fees of all transactions it displaces. An attacker can attach a large, low-fee-rate child to the commitment transaction. To replace the pinned package, the victim must pay fees exceeding the total of the attacker's bloated child, which can be hundreds of thousands of satoshis even though the child has no economic value. This makes RBF-based fee bumping prohibitively expensive.

Why pinning matters for security: Lightning HTLCs have timelocks. If an attacker pins the victim's commitment transaction long enough for those timelocks to expire, the attacker can claim HTLC outputs they are not entitled to. Pinning is not just an inconvenience: it is a potential theft vector.

The CPFP Carve-Out: A Partial Fix

In November 2019, Bitcoin Core 0.19 introduced the CPFP carve-out, a special mempool exception proposed by Matt Corallo. The rule allows one additional child transaction to exceed the 25-descendant limit, provided that child has exactly one unconfirmed ancestor and is under 10,000 vB.

This was designed specifically for Lightning: even if the attacker fills the descendant limit via their anchor output, the victim gets one extra slot for a CPFP child. Lightning implementations adopted anchor outputs (two extra outputs on each commitment transaction, one per party) to take advantage of this rule.

The carve-out had significant limitations. It only works for two-party protocols (it permits exactly one extra descendant). It does not solve RBF rule 3 pinning. And it was incompatible with the planned cluster mempool redesign, meaning it was always destined to be replaced.

V3 Transaction Policy (TRUC)

V3 transactions, specified in BIP 431, are Bitcoin transactions with nVersion=3 that opt into a restricted set of mempool relay policies. The formal name is TRUC: Topologically Restricted Until Confirmation. Proposed by Gloria Zhao and shipped in Bitcoin Core 28.0 (October 2024), TRUC replaces the blunt descendant limits with a tight, pinning-resistant topology.

The topology rules

TRUC transactions enforce a strict set of constraints on unconfirmed transaction graphs:

• A TRUC transaction may have at most one unconfirmed ancestor (its parent).
• A TRUC transaction may have at most one unconfirmed descendant (its child).
• The parent TRUC transaction is limited to 10,000 vB.
• A child TRUC transaction (one with an unconfirmed TRUC parent) is limited to 1,000 vB.
• All unconfirmed ancestors of a TRUC transaction must also be TRUC.
• TRUC transactions signal replaceability automatically, regardless of BIP 125 signaling.

The maximum unconfirmed cluster under these rules is exactly two transactions: one parent and one child. This eliminates the descendant limit attack entirely, because there is no room for an attacker to attach 24 additional children.

Sibling eviction

TRUC introduces a new mechanism called sibling eviction. When a TRUC parent already has one child and a new, more incentive-compatible child is submitted, the old child is evicted and replaced. This is the key anti-pinning property: even if an attacker broadcasts a low-fee child first, the victim can replace it by submitting a higher-fee child. Because the child is limited to 1,000 vB, the cost of replacement is bounded and predictable.

Package Relay: Submitting Parent and Child Together

V3 solves the pinning problem, but there is a second prerequisite for reliable fee bumping: package relay. Without package relay, a low-fee parent transaction is rejected by nodes individually before any child can reference it. The child that would pay for the parent never reaches the mempool because the parent was never admitted.

Package relay, specified in BIP 331, allows nodes to evaluate a group of related transactions as a unit. The initial implementation, shipped in Bitcoin Core 28.0, supports one-parent-one-child (1p1c) packages: a parent transaction that is below the mempool minimum fee rate can be submitted alongside a fee-paying child. The package fee rate (total fees divided by total size) determines admission.

How 1p1c relay works

When a node receives a transaction with a fee rate below the mempool minimum, it opportunistically pairs it with a child transaction spending one of its outputs. The pair is evaluated together: if the combined package fee rate is sufficient, both are admitted. This uses the existing P2P protocol without requiring new message types.

Bitcoin Core 30.0 (October 2025) improved 1p1c relay to handle children that have additional unconfirmed parents already in the mempool, broadening the set of valid packages. Full ancestor package relay (beyond 1p1c) remains under development and is tracked in Bitcoin Core issue #27463.

Why both are needed: V3 prevents pinning but does not help if the parent is rejected before the child arrives. Package relay ensures the parent enters the mempool but does not prevent pinning on its own. Only the combination of TRUC topology rules and package relay delivers reliable, unpinnable fee bumping for Lightning commitment transactions.

Pay-to-Anchor: A Better Anchor Output

Current Lightning anchor outputs use P2WSH scripts that require a signature from the channel party (with a fallback that anyone can spend after 16 blocks). Each commitment transaction includes two anchor outputs, one per party, each worth 330 satoshis. This works, but it wastes block space and requires each party to maintain a reserve of confirmed UTXOs for fee bumping.

Bitcoin Core 28.0 introduced a new standard output type called Pay-to-Anchor (P2A), defined by the output script OP_1 <0x4e73>. P2A outputs require no witness data to spend: they are keyless. Anyone can create the CPFP child transaction, not just the channel participants. The dust threshold for P2A is 240 satoshis, lower than the 330 satoshis required by current anchors.

With TRUC and P2A, Lightning channels can move from two 330-satoshi anchor outputs to a single P2A output. This reduces on-chain footprint, eliminates the need for each party to hold their own anchor, and removes the pinning vector entirely because TRUC limits the child count to one and sibling eviction allows replacement.

Ephemeral dust

Bitcoin Core 29.0 (April 2025) added the ephemeral dust policy, allowing zero-fee TRUC transactions to contain outputs below the dust threshold as long as those outputs are spent within the same package. This enables commitment transactions with zero-value anchor outputs that never actually materialize in the UTXO set: the anchor is created and spent in the same block. The result is a commitment transaction that pays zero fees and has zero permanent on-chain cost from the anchor output.

A Force Close: Before and After

To see how these changes interact in practice, consider a concrete Lightning force-close scenario.

Before v3 and package relay

1. Alice needs to force-close her channel with Bob. She broadcasts her commitment transaction, which was signed days ago at 10 sat/vB.
2. Since then, fees have spiked. The mempool minimum fee rate is now 25 sat/vB. Nodes reject Alice's commitment transaction on arrival.
3. Alice tries to CPFP via her anchor output, but without package relay, the parent commitment transaction must enter the mempool first. It was already rejected, so her CPFP child has nothing to reference.
4. Bob, acting maliciously, broadcasts his version of the commitment transaction (which uses a slightly different fee) and attaches 24 child transactions to his anchor output, filling the descendant limit.
5. Alice tries to use the CPFP carve-out to attach a fee-bumping child to her anchor output. Even if it works locally, mempool partitioning may prevent her child from reaching miners. Bob's pinned version sits in the mempool at an unconfirmable fee rate.
6. Time passes. HTLC timelocks expire. Bob claims HTLC outputs he should not be entitled to.

After v3 and package relay

1. Alice needs to force-close. Her commitment transaction is a TRUC transaction (nVersion=3) with a single P2A anchor output, set at zero or minimal fee.
2. Alice creates a child transaction that spends the P2A output and sets an appropriate fee for current conditions. She submits both as a 1p1c package.
3. The package is evaluated as a unit. Even though the parent is below the mempool minimum, the child's fee pays for both. The package enters the mempool.
4. Bob tries to broadcast a competing commitment transaction with a low-fee child. Alice uses sibling eviction: she submits a higher-fee child that replaces Bob's, since TRUC only allows one child.
5. The commitment transaction confirms within the timelock window. Alice recovers her funds, including all HTLC outputs.

Eliminating update_fee

One underappreciated consequence of v3 and package relay is that the Lightning protocol's update_fee message may become unnecessary. Today, channel peers must periodically renegotiate the fee rate embedded in their commitment transactions. This creates a stream of problems: fee disagreements trigger unnecessary force closes, the message adds protocol complexity, and the negotiated rate is still a guess about future conditions.

With TRUC and package relay, commitment transactions can be signed at a static minimal fee rate (even zero, using ephemeral dust). Fee determination happens at broadcast time, when actual network conditions are known. The update_fee message, along with its failure modes, can be retired entirely.

Implementation Status and Timeline

The infrastructure layer in Bitcoin Core has shipped. The Lightning adoption is underway but not yet complete.

The transition from legacy anchor channels to TRUC-based channels is not trivial. One constraint: the 10,000 vB parent limit for TRUC transactions means that the maximum number of in-flight HTLCs per commitment transaction drops from 483 to approximately 113. For routing nodes that handle high volumes, this is a meaningful change. For end-user wallets, which rarely approach either limit, it is a non-issue.

Cluster Mempool: The Next Step

The v3/TRUC policy is designed to work within the current mempool architecture, but Bitcoin Core is undergoing a deeper redesign called cluster mempool (targeted for version 31.0). Cluster mempool replaces the legacy per-transaction ancestor and descendant limits with bounded clusters of related transactions, capped at 64 transactions or 101 kB per cluster.

Cluster mempool will remove the CPFP carve-out entirely (it is incompatible with the new architecture). TRUC and sibling eviction are the designated replacement, which is why Lightning implementations need to adopt v3 commitment transactions before cluster mempool ships. The transition path is: anchor outputs (current) to TRUC + P2A anchors (near-term) to whatever further optimizations cluster mempool enables (longer-term).

How Spark Avoids the Problem Entirely

Spark takes a fundamentally different approach to Bitcoin scaling that sidesteps the fee-bumping problem. As a statechain-based Layer 2, Spark does not use payment channels and does not require pre-signed commitment transactions. Routine payments transfer ownership of on-chain UTXOs off-chain by rotating key shares between participants and Spark operators, rather than by constructing and broadcasting channel state transactions.

This means Spark users never face the scenario described above: there are no pre-signed transactions with stale fee rates, no counterparty anchor outputs to pin, and no HTLC timelocks racing against mempool congestion. Spark exits to Layer 1 use pre-signed exit transactions, but these are unilateral (no adversarial counterparty can pin them) and can be constructed using TRUC/P2A for reliable fee bumping when needed.

For developers building on Bitcoin, this is a meaningful architectural distinction. Lightning's channel-based model requires increasingly sophisticated mempool policy to remain secure, while Spark's statechain model avoids the entire class of fee-bumping and pinning concerns. Both approaches have different trust tradeoffs, but the operational complexity differs significantly.

What This Means for Developers and Node Operators

If you run a Lightning channel, the practical implications of v3 and package relay are significant:

• Upgrade your Bitcoin Core node to 28.0 or later to support TRUC relay and 1p1c packages. Your node will relay v3 transactions from peers even before your Lightning implementation uses them.
• Watch for your Lightning implementation (LND, Core Lightning, Eclair, LDK) to release TRUC-based commitment transaction support. This will likely require opening new channels, as existing channels use the legacy anchor format.
• The HTLC count reduction (from 483 to ~113 per commitment) may affect routing nodes. Evaluate whether your routing volume approaches this limit.
• The elimination of update_fee will simplify channel management and reduce unnecessary force closes caused by fee disagreements.

For developers building Bitcoin payment applications, the Spark SDK offers an alternative that avoids fee-bumping complexity entirely. Spark transfers settle instantly without on-chain transactions, and the SDK handles all protocol-level details. For applications that also need Lightning interoperability, Spark includes native Lightning support through Spark Service Providers.

Conclusion

V3 transaction policy and package relay represent years of careful engineering to solve one of Lightning's most fundamental security challenges. By restricting unconfirmed transaction topology to a single parent-child pair and enabling package evaluation at the relay layer, these changes make fee bumping predictable and resistant to adversarial pinning. The CPFP carve-out hack can be retired. The update_fee message can be eliminated. And Lightning force closes become significantly more reliable.

The Bitcoin Core infrastructure is in place. The next phase is Lightning implementation adoption: transitioning from legacy anchor channels to TRUC-based commitment transactions with P2A outputs. This transition is well underway, and the result will be a Lightning Network with meaningfully stronger security guarantees against fee manipulation attacks.

For a deeper look at the fee dynamics that drive these changes, see Bitcoin Fee Market Dynamics. For more on how mempool congestion affects Layer 2 protocols, and how different scaling solutions handle on-chain costs, explore the Bitcoin Layer 2 comparison.

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.