How a low-fee parent and a fee-paying child can travel through the network together

TL;DR
Package relay lets Bitcoin nodes evaluate a low-fee parent and a fee-paying child together. P2A gives the child a compact, keyless output to spend, while ephemeral dust permits that anchor to carry zero value when it is created and spent in the same package. For practical deployments, Bitcoin Core 29.0 is the feature minimum and 31.0 is the preferred engineering baseline.

Got curious? keep reading the entire article.

---

You create a Bitcoin transaction today.

It is valid, fully signed, and ready to be broadcast.

But it may not be used today.

Perhaps it belongs to a Lightning channel, a vault, an inheritance plan, or another system where transactions are prepared in advance and released only when a specific event occurs.

When that moment arrives, the fee market may look completely different.

The transaction that was economical when it was signed may now be too cheap for nodes to relay or for miners to confirm. And if the original signers are unavailable, changing the transaction may no longer be possible.

Package relay and ephemeral anchors address this problem. They allow a transaction to be prepared with little or no fee and later accompanied by a second transaction that pays for both.

The result is a fee-bumping mechanism designed for transactions whose authorization must remain fixed while their confirmation priority remains flexible.

The Fee Problem of Transactions Signed in Advance

For a normal wallet payment, an insufficient fee is inconvenient but usually manageable. The wallet can create a replacement transaction with a higher fee, ask the user to approve it, and sign again.

A pre-signed transaction is different.

Its inputs, outputs, locktime, and fee may have been agreed long before broadcast. The signatures authorize that exact transaction. Changing an output or reducing the amount sent to change the fee normally changes the transaction digest and invalidates the signatures.

That creates a difficult choice. The transaction can overpay in advance, wasting money whenever fees remain low. Or it can choose a modest fee and risk becoming difficult to relay when the network is busy.

The longer the delay between signing and broadcast, the less reliable any fee estimate becomes.

Why the Obvious Solution Used to Fail

The natural idea is to attach a second transaction that spends an output from the first and pays a higher fee.

This technique is called Child Pays for Parent, or CPFP. A miner cannot collect the child transaction fee without also including the parent, because the child spends an output that does not exist until the parent is confirmed.

Economically, the two transactions belong together.

Historically, transaction relay did not always see them that way. A node could receive the low-fee parent first and reject it. The child would then refer to an unknown output and could not solve the problem because its parent was missing from the mempool.

The parent needed the child to justify its fee, while the child needed the parent to be accepted. Each transaction was evaluated before the node had the complete picture.

What Package Relay Changes

Package relay allows a node to consider related unconfirmed transactions together.

The parent and child remain separate Bitcoin transactions. Each must still be valid under consensus rules. What changes is the mempool admission decision: the node can evaluate whether their combined fees are sufficient for their combined virtual size.

Imagine a 300 vB parent that pays no fee and a 150 vB child that pays 900 satoshis. The parent alone has a feerate of zero. The child alone cannot be accepted without its parent. Together, however, the package pays 900 satoshis across 450 vB, producing an effective feerate of 2 sat/vB.

If that package feerate satisfies the node’s current requirements, both transactions can enter the mempool and propagate.

The important change is not that Bitcoin combines the transactions into one. It is that relay policy can evaluate the economic relationship between them.

The Role of an Anchor Output

CPFP needs an output in the parent that the fee-paying child can spend.

An anchor output is a small output created specifically for that purpose. It gives a future transaction a place to attach, much like a hook left on the parent transaction for fee management.

Without an anchor, the party responsible for fee-bumping may not control any parent output. Or the only available output may be a protected payment that should not be spent by an operational fee-management process.

A dedicated anchor separates authorization from fee-bumping. The parent decides where the bitcoin is allowed to go. The child only decides how much additional fee should be paid to confirm that already-authorized transaction.

Why Pay to Anchor Is Different

Pay to Anchor, usually shortened to P2A, is a compact keyless output type used for this fee-bumping role.

Its script is OP_1 followed by the two-byte witness program 0x4e73. No signature and no witness data are required to spend it under standard policy.

This means the parent does not need to assign the anchor to a particular public key. A wallet, a watchtower, a service, or another party can create the child transaction and contribute its own input to pay the fee.

That last point matters when the anchor carries zero satoshis. The child spends the anchor to establish the dependency, but it funds the package fee from an additional UTXO.

The advantage is interoperability. The entity that helps the transaction confirm does not need privileged signing material from the parent. The trade-off is that anyone can attempt to spend the anchor, so the surrounding relay policy must make malicious or low-quality children replaceable.

What Makes the Anchor Ephemeral

P2A and ephemeral dust are related, but they are not the same rule.

P2A defines the keyless output. Ephemeral dust policy allows a transaction to create one dust output – potentially a zero-value P2A output – when the transaction itself pays zero fee and the dust output is spent as part of the same unconfirmed package.

The anchor is called ephemeral because it is not intended to remain as a long-lived UTXO. It exists to connect the parent to the fee-paying child.

This is a policy expectation, not a covenant. Bitcoin consensus does not force every miner to include the child whenever it includes the parent. Standard relay and mining behavior are designed around the package, but the rule does not alter what blocks are valid.

That distinction is essential: ephemeral anchors improve transaction propagation and fee management without changing Bitcoin consensus.

Why TRUC Transactions Matter

A keyless anchor can be spent by anyone. Without additional constraints, an attacker could try to attach a large or low-fee child and make the intended fee bump harder to propagate.

Topologically Restricted Until Confirmation transactions, known as TRUC or version 3 transactions, reduce this risk by keeping the unconfirmed structure deliberately small.

In the standard TRUC pattern, a transaction can have at most one unconfirmed parent and one unconfirmed child. The fee-bumping child is also limited in size. These restrictions make replacement decisions easier for nodes and give honest users tighter bounds on the cost of replacing an unwanted child.

TRUC policy also supports sibling eviction: when a new child is more incentive-compatible, it can replace the existing child instead of being blocked merely because the parent already has one descendant.

For a P2A anchor, this is the practical anti-pinning layer. P2A supplies the hook. TRUC makes competition for that hook manageable.

Package Relay Is Not a Consensus Change

Package relay, P2A standardness, ephemeral dust, and TRUC are mempool and relay policies.

They do not add an opcode. They do not require a soft fork. Older nodes can still validate a block containing these transactions according to the existing consensus rules, even if they would not have relayed the same transactions through their own mempools.

This also means support is not perfectly uniform. A transaction package may encounter peers, services, or miners with different policies. Wallets and contracting systems should therefore monitor propagation, connect to multiple modern peers, and maintain operational fallbacks for urgent transactions.

Policy can make fee-bumping more reliable. It cannot turn network propagation into a consensus guarantee.

What This Means for Vaults and Delayed Transactions

Vaults and other delayed-spend systems often need to authorize a transaction before the fee required for confirmation is known.

A practical default construction is a zero-fee TRUC parent with one zero-value P2A output. When the transaction becomes eligible for broadcast, a small TRUC child spends the P2A output, adds a confirmed fee input, and pays the package fee required by current conditions.

The parent does not need to be modified. Its protected outputs remain unchanged. Its signatures remain valid. Only the child is created at broadcast time.

For B-SSL, this makes P2A and ephemeral anchors a natural default for Path 1 fee-bumping: the approved parent transaction can remain bound to its original template while the child adjusts confirmation priority after the operational delay expires.

The mechanism does not strengthen the vault’s consensus-enforced spending conditions. It strengthens the operational ability to relay and confirm an already-valid spend under an uncertain fee market.

Conclusion

A Bitcoin signature can fix where funds are allowed to move, but it cannot predict the fee market that will exist when the transaction is finally broadcast.

Package relay separates those two decisions.

The parent carries the authorization. The child carries the fee. P2A provides a compact, keyless connection between them, while ephemeral dust allows that connection to have no economic value of its own. TRUC policy keeps the unconfirmed topology small enough for reliable replacement and anti-pinning behavior.

Together, these mechanisms make pre-signed and delayed transactions more practical. They allow Bitcoin systems to preserve strict transaction templates without forcing users to guess future fees or keep every signer permanently available.

The transaction can be decided in advance. Its fee can be decided when the network finally sees it.

Technical Notes

Bitcoin Core 28.0-31.0

The following details refine the simplified mental model used above. They describe Bitcoin Core policy as of versions 28.0 through 31.0.

The implementation path is incremental. Bitcoin Core 28.0 introduced the main building blocks. Bitcoin Core 29.0 added ephemeral dust. Versions 30.0 and 31.0 broadened package relay and replaced older mempool assumptions with more general cluster-aware logic.

Bitcoin Core	Relevant changes	Meaning for P2A / ephemeral anchors
28.0	Limited opportunistic one-parent-one-child package relay; version 3/TRUC standardness; P2A spends made standard; limited package RBF; zero-fee parents supported in the TRUC package case.	Foundation release. Useful for P2A and TRUC experiments, but it does not yet provide standard zero-value ephemeral dust. The release notes explicitly describe P2P package relay as limited and not yet reliable under adversarial conditions.
29.0	Ephemeral dust permits one dust output in a zero-fee transaction when the unconfirmed package spends that dust output. The -mempoolfullrbf option is removed after full RBF was made the default in 28.0.	Minimum Bitcoin Core version for the usual zero-value P2A ephemeral-anchor construction under standard policy.
30.0	One-parent-one-child package relay works when the child is connected to additional parents already in the mempool; submitpackage no longer requires every unconfirmed parent in the submitted package; the wallet can create and spend TRUC transactions.	Improves propagation and wallet integration. The package can be connected to broader existing mempool topology while only one missing parent needs fee-bumping.
31.0	Cluster mempool replaces ancestor/descendant accounting with cluster and chunk logic; RBF uses feerate-diagram improvement; CPFP carveout is removed; zero-fee parents in one-parent-one-child relay are extended to non-TRUC packages.	Preferred engineering baseline. It provides the most mature package-aware mempool behavior in this version range, while TRUC remains the recommended bounded topology for P2A anti-pinning.

Minimum and preferred baseline

Feature minimum: Bitcoin Core 29.0 for the standard zero-value ephemeral-dust pattern. Preferred engineering baseline: Bitcoin Core 31.0, while keeping the parent and child TRUC for bounded anti-pinning behavior.

Recommended default construction

• Parent: nVersion = 3, zero fee, sigop-adjusted virtual size no larger than 10,000 vB, and exactly one zero-value P2A anchor output when using the ephemeral-dust pattern.
• Child: nVersion = 3, spends the P2A output, adds one or more confirmed fee inputs, has sigop-adjusted virtual size no larger than 1,000 vB, and pays the target package fee.
• The target feerate is calculated from the total fees and total virtual size of the parent and child. The parent is not modified or re-signed.
• The child should use a replacement-compatible fee policy and be monitored until the package is observed across multiple peers and, where available, mining interfaces.

BIP status and terminology

• BIP 331 is a draft specification for dedicated ancestor-package relay messages. Bitcoin Core 28.0 through 31.0 should not be described as a complete deployment of BIP 331; Core uses opportunistic one-parent-one-child relay through the existing transaction-relay protocol.
• BIP 431 is a draft informational document describing TRUC policy. Its core version 3 topology restrictions are implemented in Bitcoin Core.
• BIP 433 is a draft informational document describing P2A. The P2A standardness change was deployed in Bitcoin Core 28.0 before the BIP received its number.
• The term ephemeral anchor commonly refers to combining an anchor output – often P2A – with ephemeral-dust policy. The two concepts should remain distinct in technical documentation.

Operational limitations

• All of these mechanisms are relay and mining policy, not consensus. Adoption can vary across nodes and miners.
• P2A is keyless. Any party can create a child. TRUC, package RBF, and sibling eviction reduce pinning risk but do not eliminate every propagation or adversarial-network risk.
• A zero-value P2A output does not fund its own child. The fee-paying child must add another input with sufficient value.
• A production system should use current node software, multiple broadcast paths, mempool monitoring, fee estimation at broadcast time, and an escalation path for direct package submission or miner contact when timing is critical.