A transaction can pay a higher absolute fee than the one it replaces, pay a higher feerate, and still be rejected by every node that sees it. That is not a bug in the relay code. It is the direct consequence of three documented policy limits, and the reason fee bumping is better understood as a negotiation with mempool rules than as an instruction to a miner.

The baseline is BIP-125, the opt-in full replace-by-fee signalling policy whose status the document itself records as Deployed, assigned in December 2015. Its five conditions are what a replacement has to satisfy on any node that implements the policy, and they are the rules most wallets are working within when they offer to speed a payment up. The two proposals that follow it in the record, BIP-331 on ancestor package relay and BIP-431 on topology restrictions for pinning, exist because the baseline cannot deliver what users assume it delivers. Both are still marked Draft. Reading them together answers a question that matters to anyone operating a wallet, an exchange withdrawal queue or a Lightning node: under what conditions does a fee bump actually work, and who can stop it cheaply?

The five rules, and the one that is not a feerate rule

BIP-125 specifies two signalling routes. Explicit signalling marks a transaction replaceable when any input carries an nSequence number below 0xffffffff - 1. Inherited signalling extends that status to descendants: a transaction that does not signal is still replaceable for as long as any one of its ancestors signals and remains unconfirmed. That is the document’s own formulation, and it also tells receiving wallets to carry their suspicion or their waiting policy down the descendant chain.

Replacement then has to satisfy five conditions. The originals must signal. The replacement may include an unconfirmed input only if that input was already in one of the originals. It must pay an absolute fee at least equal to the sum of the fees of the originals. It must pay for its own bandwidth at or above the node’s minimum relay feerate. And the number of original transactions plus the descendants evicted from the mempool must not exceed one hundred.

The fourth condition is narrower than it reads. It compares the replacement against the node’s minimum relay feerate, not against the feerate of the transaction being replaced. BIP-125’s own worked example makes the arithmetic concrete: at a minimum relay feerate of one satoshi per byte and a replacement of 500 bytes, the replacement must pay at least 500 satoshis more than the sum of the originals. A 500-byte original paying 2 satoshis per byte puts 1,000 satoshis in fees; replacing it with a 500-byte transaction at 3 satoshis per byte pays 1,500, a delta of exactly the 500 required. The bandwidth charge is cleared, and nothing is left over. Shrink the replacement and it fails: a 400-byte version at 3 satoshis per byte pays 1,200 against the same 1,000, a delta of 200 where the rule asks for 400.

Nothing in the five rules requires the replacement to be more attractive to a miner than what it evicts. That gap is the opening for everything that follows, and BIP-431 states the consequence plainly when it observes that there is currently no effective rule to enforce that a replacement transaction would be more incentive compatible to keep in the mempool.

Why the unit of account is the ancestor package

Since Bitcoin Core v0.13, nodes have tracked ancestor packages rather than isolated transactions when they judge whether a transaction is worth keeping and when they select transactions for a block. BIP-331 records this as the premise for its whole design: the mempool evaluates a transaction together with its unconfirmed ancestors, and miners likewise select by feerate-with-ancestors. That is why child-pays-for-parent works at all. A cheap parent can be carried into a block by an expensive child, because the pair is what gets evaluated.

The same architecture explains the failure mode. If the replacement itself does not meet the threshold, a wallet cannot attach a child to rescue it, because the child would spend an output that the node has not accepted. BIP-331 puts it directly: a spender cannot attach a descendant to pay for replacing a conflicting transaction, since it would be rejected for spending inputs that do not exist. The relay layer, not the fee market, decides whether the bump is even expressible.

This is not a theoretical irritation for contracting protocols. BIP-331 lists the transaction types that depend on getting a presigned, time-sensitive transaction confirmed inside a window: HTLC-timeout and HTLC-success transactions in the Lightning penalty protocol, unvault-cancel transactions in Revault, refund transactions in Discreet Log Contracts, updates in Eltoo, and claim transactions in PeerSwap. In each case the feerate is negotiated or fixed long before broadcast. If the forecast was too low and no fee-bumping route exists, BIP-331 states the outcome in one sentence: attackers can steal money from their counterparties.

Two cheap levers for an adversary

BIP-431 catalogues the pinning techniques that follow from the baseline rules. The first works through absolute fees. Because a replacement must exceed the aggregate fees of everything it evicts, a counterparty can raise the bar by attaching descendants that pay a low feerate, too low for the honest party to lift the whole set through child-pays-for-parent. The attacker buys a large fee requirement cheaply, and the honest party must now outspend it rather than simply outbid the original transaction.

The second works through the conflict count. The hundred-transaction ceiling counts descendants, so an adversary can make a replacement structurally impossible rather than merely expensive. BIP-431 gives the example: if one party wants to batch-replace five transactions and each has twenty-one descendants, the replacement is rejected regardless of its fees. Five times twenty-one is a hundred and five. No fee level repairs that.

A third limitation compounds both. A transaction must meet the fee-related rules on its own; its child’s fees cannot be counted toward them. BIP-431 notes the consequence for the Lightning penalty protocol: conflicting commitment transactions signed with the same fees cannot replace each other even when accompanied by a fee-bumping child, which is why two anchor outputs exist, one for each party. The workaround is a structural concession, not a solution.

The related carve-out has its own ceiling. CPFP carve-out lets one more child be added to a transaction that would otherwise be at its descendant limit, which is what stops a counterparty from monopolising the limit. BIP-431 points out that it permits exactly one additional child, so it cannot guarantee child-pays-for-parent for more than two parties sharing a transaction, and that the cluster mempool proposal requires removing the carve-out entirely.

Why the obvious fix is rejected

The intuitive repair is to let a replacement win on feerate alone. BIP-431 devotes a section to why that has been rejected, and the arithmetic is the reason. If the absolute-fee rules were dropped and only the feerate had to double, a 100 kvB transaction paying one satoshi per byte could be replaced by a 100 vB transaction paying 200 satoshis. That is 200 satoshis to relay 100,200 vB of transaction data, below 0.002 satoshi per byte. Relay would become nearly free, and the average feerate and total absolute fees in the mempool could be driven down cheaply.

Keeping the absolute-fee rule but dropping the bandwidth rule does not rescue the idea either. An attacker could start with a 100 kvB transaction at one satoshi per byte and repeatedly shrink it while doubling the feerate, ending up paying roughly 100,000 satoshis to relay something approaching 200 kvB, an effective rate near half a satoshi per byte, under the one satoshi per byte threshold the document treats as free relay. The alternatives section also dismisses a global replacement rate limit on the grounds that, absent identity or reputation, an attacker can exhaust the quota and lock honest users out, for instance by exhausting an outpoint-based limit on a shared transaction.

That leaves an incentive-compatibility problem without a cheap static answer. BIP-431 explains that a full calculation is too computationally expensive, while static scores overestimate or underestimate and create new pinning surface. The proposals that survive are the ones that make the calculation tractable by shrinking the shape of what has to be evaluated.

What the topology restriction actually does

BIP-431’s answer is Topologically Restricted Until Confirmation: a transaction sets nVersion=3 and accepts a narrower shape in exchange for more reliable replacement. Six rules define it, and each maps to a specific attack.

  • A TRUC transaction signals replaceability whether or not it signals under BIP-125, so the opt-in cannot be half-applied.
  • All unconfirmed ancestors and all descendants of an unconfirmed TRUC transaction must also be TRUC. Confirmed non-TRUC outputs may still be spent, and a non-TRUC transaction may spend confirmed TRUC outputs, so the restriction is about the unconfirmed cluster rather than the address or the wallet.
  • An unconfirmed TRUC transaction may have at most one unconfirmed ancestor and at most one unconfirmed descendant, and the CPFP carve-out is not granted to it.
  • A TRUC transaction’s sigop-adjusted virtual size may not exceed 10,000 vB.
  • A TRUC transaction with an unconfirmed TRUC ancestor may not exceed 1,000 vB.
  • An individual TRUC transaction may sit below the mempool minimum relay feerate if the package it belongs to meets the requirement, which is what allows a zero-fee presigned transaction to be bumped at broadcast time.

The rationale is worth following rather than skipping, because the numbers are chosen against attacks rather than against user convenience. The one-parent-one-child limit bounds how many transactions a replacement can be forced to evict, which frustrates the conflict-count lever. Prohibiting a second child is what makes ancestor score usable as a measure of incentive compatibility: with a co-parent and an additional child in the picture, the ancestor feerate of the original underestimates the package, and the estimate stops being a safe bound. The 1,000 vB child limit caps the additional fees a bump can be forced to carry, reducing that upper bound by a factor of one hundred relative to a 100,000 vB descendant, while still leaving room for a child with fifteen inputs and two outputs in the document’s own calculation.

Two details show how much of this is engineering compromise rather than principle. Sibling eviction becomes feasible only because there can be at most one descendant to identify and evict. And package replace-by-fee is enabled for TRUC transactions because feerate diagrams are cheap to build when clusters are size two or smaller. The policy is tractable precisely because it is narrow.

What it does not fix

The limits of the proposal are stated in the document and should temper any claim that pinning is solved. The scope of the anti-pinning benefit is confined to the mempool of each implementing node, so how safe a transaction is depends on how much of the network has adopted the policy. A wallet that broadcasts a version 3 transaction to peers that do not implement the rules gets none of the guarantees.

TRUC also does not address pinning through absolute fees for transactions that are not TRUC, and BIP-431 notes that the cluster mempool proposal does not help with either absolute-fee pinning or pinning through the number of conflicts. Those two levers survive the more holistic redesign. Anyone who reads version 3 as a general cure is reading past the section that lists what remains open.

Status matters as much as mechanism. BIP-431 is a Draft, and its type is Informational; BIP-331 is a Draft specification. Neither document establishes that the policy is active on the network, and the implementation section lists pull requests rather than releases. A production system that depends on sibling eviction or package replace-by-fee is depending on a documented design and on whatever its peers happen to run, not on a settled network-wide rule.

What this means in practice

For a wallet or an exchange withdrawal queue, the operational lesson is that a fee bump is only as reliable as the shape of the transaction being bumped. A single-input, single-output payment that signals explicitly is close to the easy case. A batched withdrawal, a shared output between parties, or a presigned contract transaction is where the rules bite, because the adversary’s cost to raise the fee bar or to inflate the conflict count is low and the honest party’s cost to respond is not.

Receivers have a parallel obligation. BIP-125’s receiving-wallet section asks wallets that display unconfirmed transactions to either convey additional suspicion about opt-in replaceable transactions or ignore them until confirmation, and to carry that treatment down the descendant chain for as long as an ancestor remains unconfirmed. Treating an unconfirmed, explicitly replaceable payment as settled is a choice to accept the replacement risk the signal announces.

For protocol designers, the sequence in these three documents is the useful pattern. BIP-125 showed that a first-seen default could be relaxed with an opt-in signal and a bandwidth charge. BIP-331 showed that the resulting rules cannot be fixed at the relay layer alone, because a child that would pay for a replacement cannot be propagated in the first place. BIP-431 then accepted a visible cost, a narrower transaction topology, in exchange for bounds that make the incentive calculation tractable. Each step traded generality for a property that could be reasoned about, which is the opposite of how fee-bumping is usually described to users.

What would change this conclusion

Three observations would move the analysis. Measured adoption of version 3 policy across hash rate and relay nodes would convert the node-scoped caveat into a real reliability estimate; without it, the honest statement is that the guarantee is local. Release notes showing sibling eviction and package replace-by-fee shipping in a default configuration would upgrade the status question from draft to deployed. And a fee environment where blocks are consistently empty would make the whole discussion moot, because pinning only has teeth when confirmation timing has value. None of those is established by the documents reviewed here, and none should be assumed from them.

The narrow claim the evidence supports is this. Mempool policy, not miner preference, decides whether a bump is admissible, and two of the three rules that make replacement safe are also the two levers that make it attackable. BIP-431’s topology restriction reduces the attack surface for transactions that opt in and leaves the rest where BIP-125 put them. That is a meaningful improvement and a deliberately partial one.

Sources