Bitcoin Package Relay Implementations: Solving Transaction Pinning

Package Relay Component Overview

Bitcoin package relay is a set of interrelated mempool policy changes that allow nodes to evaluate groups of related transactions as a single unit rather than individually. These changes solve transaction pinning attacks that have threatened Lightning channel security since 2018. The full package relay stack consists of four components: TRUC (v3) transaction policy, Pay-to-Anchor (P2A) outputs, package RBF, and 1-parent-1-child relay. Together, they enable zero-fee presigned commitment transactions that either channel party can fee-bump at broadcast time.

The following table summarizes each component, its BIP number, implementation status, and the Bitcoin Core version that shipped it.

For deeper context on how these components interact with Lightning fee-bumping, see our research on v3 transactions and package relay.

The Pinning Problem

Transaction pinning exploits Bitcoin Core's mempool policy rules to prevent a legitimate transaction from confirming. For the Lightning Network, this is a critical security issue: if a commitment transaction or HTLC-timeout cannot confirm before its timelock expires, a counterparty can steal funds.

Two primary pinning techniques threatened Lightning channels before package relay:

• Descendant limit pinning: Bitcoin Core enforced a 25-transaction descendant limit per package. An attacker could attach 24 low-fee descendants to a commitment transaction output, filling the package so the honest party could not add a CPFP child.
• RBF Rule 3 pinning: BIP 125 requires a replacement to pay a higher absolute fee than all displaced transactions combined. An attacker could attach a large, low-feerate child to the commitment transaction, making replace-by-fee prohibitively expensive.

The first targeted fix was CPFP carve-out, shipped in Bitcoin Core 0.19 (2019). It allowed one additional child beyond the descendant limit for transactions with exactly one unconfirmed ancestor. This worked for two-party contracts like Lightning but did not generalize to multi-party protocols and was ultimately removed in Bitcoin Core 31.0 (April 2026), replaced by the TRUC and ephemeral anchor stack.

TRUC (v3) Transactions: BIP 431

TRUC stands for Topologically Restricted Until Confirmation. Any transaction with nVersion=3 opts into a stricter set of mempool policy rules defined in BIP 431. These topology restrictions eliminate the descendant and RBF pinning vectors entirely.

The core TRUC rules are:

• A TRUC transaction may have at most one unconfirmed parent
• A TRUC transaction may have at most one unconfirmed child
• The parent (root) TRUC transaction is limited to 10,000 vB
• The child TRUC transaction is limited to 1,000 vB
• TRUC transactions are always replaceable via RBF (no opt-in required)
• A TRUC parent is allowed to pay zero fees if relayed as part of a package with a fee-paying child

The 1-parent-1-child topology guarantee is what defeats pinning: an attacker cannot attach multiple descendants because the policy limits the unconfirmed chain to exactly two transactions. And because the child is capped at 1,000 vB, the cost to replace an attacker's child via sibling eviction is bounded and predictable.

For Lightning, this means commitment transactions can be pre-signed with nVersion=3 and zero fees. At broadcast time, the party that needs to force-close attaches a fee-paying child that spends the anchor output at the current market feerate. No more guessing fees weeks or months in advance during channel opens.

Pay-to-Anchor (P2A): BIP 433

Pay-to-Anchor is a new standard witness output type that provides a compact, keyless anchor for CPFP fee bumping. The scriptPubKey is OP_1 <0x4e73>, a SegWit v1 output that requires an empty witness to spend. The two bytes 0x4e73 were deliberately chosen to spell "fees" when encoded as a bech32m address (bc1pfeessrawgf).

P2A replaces the older OP_TRUE anchor pattern that Lightning implementations used previously. The advantages of P2A over the legacy approach:

• Smaller output script: 4 bytes versus 35 bytes for the equivalent P2WSH(OP_TRUE)
• Smaller spending input: empty witness versus a witness containing the OP_TRUE script
• No signature required: anyone can spend the anchor, so either channel party (or a third-party fee-bumping service) can attach the CPFP child
• Txid stability: because spending requires no variable witness data, the child transaction's txid is deterministic

Bitcoin Core 28.0 made P2A spends standard on mainnet. BIP 433 recommends combining P2A with TRUC to bound the pinning risk from an oversized, low-feerate child spending the anchor.

Ephemeral Dust and Zero-Fee Anchors

Bitcoin Core enforces a dust limit: outputs below 546 satoshis (for most script types) are non-standard and will not relay. This creates a problem for ephemeral anchors, which ideally carry zero value so they do not lock up any channel balance.

Bitcoin Core 29.0 (April 2025) introduced the ephemeral dust policy: a single dust-value output is permitted in a zero-fee TRUC transaction, provided the output is spent within the same package. The dust output is created and consumed atomically, so it never persists in the UTXO set.

The ephemeral dust policy completes the package relay stack for Lightning. A commitment transaction can now include a single P2A output with zero satoshis, pay zero fees itself, and rely entirely on the child transaction to cover the fee for both. This design is relevant not only to Lightning but also to protocols like Ark, timeout trees, and ln-symmetry.

1-Parent-1-Child Relay and Package RBF

Package relay allows a node to accept a parent transaction that would normally be rejected (because its feerate is below the mempool minimum) by evaluating it together with a fee-paying child. Bitcoin Core 28.0 shipped 1-parent-1-child (1P1C) relay, an opportunistic form that piggybacks on the existing transaction relay protocol rather than introducing new P2P messages.

When a node receives an orphan transaction (a child whose parent it does not have), it requests the missing parent from peers. If the parent is below the mempool minimum feerate, the node evaluates the parent-child pair as a package. If the combined feerate meets the threshold, both transactions enter the mempool.

Package RBF extends this: a 1P1C package can replace conflicting transactions already in the mempool, using the child's fee contribution to meet the replacement threshold. This shipped as a limited form in Bitcoin Core 28.0, restricted to cases where the resulting mempool cluster has at most two transactions.

BIP 331 specifies a more general ancestor package relay protocol with dedicated P2P messages (sendpackages, getpkgtxns, pkgtxns). This would allow nodes to explicitly request and relay multi-transaction ancestor packages. As of mid-2026, BIP 331 remains a draft and has not shipped in any Bitcoin Core release. The 1P1C approach handles the most critical use case (Lightning commitment transactions) without requiring protocol-level changes.

Lightning Implementation Adoption

The Lightning specification for zero-fee commitment transactions using ephemeral anchors was defined in BOLTs #1228, authored by Bastien Teinturier. The spec introduces a new channel type (feature bits 40/41) that uses TRUC commitment transactions with a single P2A ephemeral anchor. This was merged into the BOLT specification in May 2026.

All major implementations already support the older anchor output channel type (with two anchor outputs per commitment transaction and pre-calculated fees). The migration path to zero-fee TRUC commitments with a single P2A anchor is incremental: new channels can adopt the new type, while existing channels continue operating under the legacy format. Channel splicing may eventually provide a path to upgrade existing channels in place.

Cluster Mempool and the End of Carve-Out

Cluster mempool, shipped in Bitcoin Core 31.0 (April 2026), replaces the legacy ancestor and descendant limit system with cluster-based limits: a maximum of 64 transactions and 101 kvB per cluster. This architectural change eliminated the need for the CPFP carve-out exception and enabled more accurate fee estimation and block template construction.

With cluster mempool, RBF evaluation uses feerate diagrams to determine whether a replacement genuinely improves miner revenue. This eliminates all known cases where a replacement could make the mempool worse off, closing a class of issues that existed under the old BIP 125 rules. For TRUC transactions specifically, the 1-parent-1-child topology maps cleanly to the cluster model: each TRUC package is its own cluster of size two, making replacement evaluation straightforward.

Remaining Attack Surface: Replacement Cycling

Replacement cycling is a more sophisticated mempool attack disclosed by Antoine Riard in October 2023. The attacker repeatedly uses RBF to evict a victim's HTLC-timeout transaction before it confirms, then lets the replacement expire from the mempool, cycling the process until the timelock expires.

TRUC transactions and package relay significantly reduce but do not fully eliminate the replacement cycling attack surface. The bounded child size (1,000 vB) and mandatory replaceability make cycling more expensive and less reliable for the attacker. Additional mitigations at the application layer (rebroadcasting, watchtower monitoring, longer CLTV deltas) further reduce practical risk. For a detailed analysis, see our research on transaction pinning attacks.

How Package Relay Improves Lightning Force-Closes

Before package relay, a Lightning force-close required the commitment transaction to include a pre-estimated fee that might be too low (stuck in the mempool) or too high (overpaying). The complete package relay stack changes this workflow:

1. The commitment transaction is pre-signed with nVersion=3 and zero fees
2. A single P2A anchor output (zero or dust value) is included in the commitment transaction
3. At force-close time, the broadcasting party creates a child transaction that spends the P2A anchor and pays the appropriate feerate based on current mempool conditions
4. The parent-child pair is relayed as a 1P1C package, entering the mempool together
5. If the counterparty broadcasts a competing commitment transaction, package RBF allows the honest party's package to replace it using the child's fee contribution

This flow eliminates feerate guessing, reduces anchor output overhead from two outputs to one, and makes force-closes reliable regardless of fee market conditions. Layer 2 protocols built on Bitcoin, including Spark, benefit from these improvements to the base layer transaction relay infrastructure.

Development Timeline

Package relay has been one of the longest-running development efforts in Bitcoin Core, spanning multiple years and dozens of pull requests. The following timeline tracks the major milestones.

For a complete reference of Bitcoin consensus and policy proposals, see our BIP reference guide.

Frequently Asked Questions

What is package relay in Bitcoin?

Package relay is a Bitcoin Core feature that lets nodes evaluate a group of related transactions as a single unit rather than individually. This means a parent transaction that pays zero fees can enter the mempool if it is submitted alongside a child transaction that pays enough fees for both. Bitcoin Core 28.0 shipped 1-parent-1-child package relay, which handles the most critical use case: fee-bumping pre-signed Lightning commitment transactions.

What are TRUC (v3) transactions?

TRUC stands for Topologically Restricted Until Confirmation. Defined in BIP 431, these are transactions with nVersion=3 that opt into stricter mempool policy rules: at most one unconfirmed parent, at most one unconfirmed child (capped at 1,000 vB), and mandatory replaceability. These restrictions prevent transaction pinning attacks by bounding the topology of unconfirmed transaction chains. TRUC became standard on mainnet in Bitcoin Core 28.0 (October 2024).

How does package relay fix Lightning transaction pinning?

Lightning commitment transactions can be pinned when an attacker attaches descendants that prevent fee bumping. TRUC transactions solve this by limiting the unconfirmed chain to exactly one parent and one child. The attacker cannot attach additional descendants, and the bounded child size (1,000 vB) makes sibling eviction via RBF cheap and predictable. With the ephemeral anchor pattern, either channel party can attach a CPFP child at the current market feerate.

What is a Pay-to-Anchor (P2A) output?

Pay-to-Anchor is a keyless SegWit v1 output type defined in BIP 433. Its script is OP_1 <0x4e73>, and spending it requires an empty witness (no signature). P2A provides a compact, anyone-can-spend hook for CPFP fee bumping in presigned transactions. It replaced the older P2WSH(OP_TRUE) anchor pattern with a smaller on-chain footprint. Bitcoin Core 28.0 made P2A spends standard.

What is the difference between 1P1C relay and full ancestor package relay (BIP 331)?

1-parent-1-child (1P1C) relay is an opportunistic mechanism that uses the existing transaction relay protocol. When a node receives an orphan transaction, it requests the missing parent and evaluates the pair as a package. BIP 331 proposes dedicated P2P messages for requesting and relaying multi-transaction ancestor packages, enabling more complex package topologies. 1P1C is deployed in Bitcoin Core 28.0+; BIP 331 remains a draft.

Does package relay eliminate all Lightning pinning risks?

No. Package relay and TRUC significantly reduce the pinning attack surface but do not eliminate all risks. Replacement cycling remains a theoretical concern, though TRUC's bounded child size and mandatory replaceability make the attack more expensive. Lightning implementations apply additional mitigations including rebroadcasting logic, watchtower monitoring, and conservative CLTV delta settings.

Which Bitcoin Core version do I need for package relay?

Bitcoin Core 28.0 (October 2024) is the minimum version for TRUC transactions, P2A, 1P1C relay, and limited package RBF. Version 29.0 (April 2025) adds the ephemeral dust policy needed for zero-value anchor outputs. Version 31.0 (April 2026) ships cluster mempool and removes the legacy CPFP carve-out. Running the latest release provides the most complete package relay support.

This tool is for informational purposes only and does not constitute financial advice. Implementation statuses reflect publicly available information as of mid-2026 and may change with new Bitcoin Core releases and Lightning specification updates. Always verify current implementation details in the relevant project repositories before building on these features.