BIP 125 Replace-by-Fee Explained for Bitcoin Miners

BIP 125 replace-by-fee explained for miners: understand opt-in signalling, replacement conditions, inherited replaceability and wallet confirmation risk.

What replace-by-fee mean

Replace-by-fee is node mempool policy that permits one unconfirmed transaction to replace conflicting transactions when stated conditions are met. It does not rewrite a confirmed block and is not a consensus rule. Miners ultimately choose valid transactions for their templates. At the same time, each relay node decides whether a proposed replacement qualifies for its local mempool and propagation policy.

Start with the validating node, because the ASIC only hashes the candidate header it receives. Record the node release and the pool component that assembled the block. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.

Opt-in signalling

BIP 125 defines explicit replaceability when an input sequence number is below the specified final threshold. A transaction can also inherit replaceability from an unconfirmed ancestor that signals. Wallets should therefore inspect the complete unconfirmed ancestry, not just the payment transaction’s own sequence fields. Once an ancestor confirms, inherited signalling can change for descendants.

Treat status dashboards as observations, not as the source of truth. Compare them with an independently operated node and retain the raw deployment or template response. Period boundaries, chain reorganisations and cached pool pages can otherwise make a correct-looking percentage describe the wrong state.

The five replacement conditions

The original policy requires the replacement to conflict with one or more transactions that signal replaceability, avoid introducing unrelated unconfirmed inputs, pay at least the originals’ absolute fee, add enough incremental relay fee for its own bandwidth and evict no more than the policy limit of original transactions and descendants.

Current Bitcoin Core policy must be checked because implementation defaults and broader full-RBF behaviour can evolve.

Build the failure response before the boundary arrives. Define which rejection messages trigger an alert, who can pause a template source and how failover is prevented from returning miners to the same faulty validation stack. A second hostname is not independent when both endpoints share one node.

Absolute fee versus feerate

A replacement can have a higher total fee while still consuming more weight. So operators must compare both absolute incentive and feerate. The incremental relay requirement compensates for repeated bandwidth and validation. A wallet that raises only satoshis per virtual byte without satisfying the original absolute fee may fail. Conversely, overpaying a replacement does not guarantee inclusion if a miner uses different policy or priorities.

Separate readiness, signalling and enforcement in the operating log. Readiness is a claim about software and process, signalling is data carried by blocks, and enforcement is a validation result. Combining them into a single supported or unsupported label hides the point at which revenue is actually at risk.

Receiving-wallet safety

BIP 125 recommends treating explicitly replaceable unconfirmed payments with caution because the sender may publish a conflicting version. Non-signalling is not a guarantee against replacement, double spend, reorganisation or miner policy. A business should define confirmation thresholds from value and risk, verify final settlement on its own node and avoid delivering irreversible goods solely from a mempool label.

Map responsibility across the full path: validating node, template server, pool protocol, proxy, firmware and ASIC. For each layer, state what it can alter and what it merely relays. This prevents a version-bit setting in firmware from being mistaken for complete consensus-rule support. Relate that responsibility map to the pool and job-control boundary in our Stratum V2 guide.

Mining and pool behaviour

A pool may run full-RBF, opt-in RBF or custom transaction-selection policy. Its nodes should agree or template contents can flap across failover. Monitor replacement acceptance, eviction sets, ancestor data and template feerate. A pool does not need to include the first transaction seen.

It must include a valid non-conflicting set and ensure payout or accounting systems do not mistake an evicted TXID for confirmed income.

Test the primary and failover paths with the same checks. Compare chain tip, chainwork, deployment state, required rules and template age, then save the result with a timestamp. The process should be repeatable by another operator without relying on an undocumented pool conversation.

Operator test plan

Create controlled signalling and non-signalling conflicts on test infrastructure. Exercise inherited replaceability, added unconfirmed inputs, absolute-fee and incremental-relay boundaries, plus the eviction-count limit. Compare mempool results across every template node and verify block candidates after a policy change. Record client version and configuration so a later wallet complaint can be reproduced without assuming every public node uses identical policy.

Turn the conclusion into a business decision. State which chain and settlement venues the operation intends to serve, the maximum acceptable stale-block exposure and the point at which mining pauses. This connects protocol evidence to electricity cost, pool revenue and payout finality.

Operator decision record

A concise decision record for BIP 125 replace by fee should name the source documents, their dates, the node release tested, the responsible pool or template provider and the exact trigger for action. Include screenshots or machine-readable output for the deployment state. But keep the raw node response as the stronger evidence.

State whether a change affects policy, block construction or consensus validity, because those layers have different failure costs.

Run the check on every production and failover path. Confirm that monitoring alerts on stale templates, unexpected chain tips, rejected proposals and a rise in stale shares. Keep rollback instructions for node and pool configuration. But do not roll back across an active consensus boundary without understanding the rules the older release enforces.

If the evidence conflicts, pause the affected path and investigate before committing more electricity to uncertain work.

For related background, read our plain-English BIP-110 guide and technical BIP-110 review. Those articles use a modern proposal to show why signalling, activation, template construction and accepted chain history must be examined separately.

Conclusion

Bip 125 replace by fee is best understood as a defined interaction between validating software, mining infrastructure and economic acceptance. The safest operator does not infer consensus from a dashboard percentage or a pool slogan. They verify the rule source, the activation boundary, the template fields and the chain their payouts ultimately settle on.

That discipline reduces the chance of hashing an invalid or commercially unwanted block.