Mempool replacement: count spend attempts without double counting
A mempool feed can contain several transaction identifiers competing to spend the same bitcoin output. Adding their values as separate payments overstates what can settle on one selected chain. Research should preserve the attempts while separately counting confirmed outcomes and unresolved spend families.
BIP 125 describes opt-in replacement signaling and a replacement policy. It is a specification of that policy, not a promise that every current node has identical relay behavior. Record the actual node software and observation conditions rather than inferring today’s whole network from one feed.
Make the input conflict the counting object
For each observed transaction, retain first-seen time, transaction identifier, input outpoints, output values, fee and final observed status. An outpoint is the previous transaction identifier plus output index. Transactions sharing an input cannot both spend that input in the same valid selected-chain history.
Construct a conflict graph linking attempts that share inputs. A connected component is a useful investigation family, but does not necessarily represent one unchanged payment intention. A replacement can alter outputs or recipients; a later transaction can also add inputs and connect previously separate groups. Preserve the graph and each version’s proposed outputs.
Separate three counts: observed transaction attempts, conflict families, and confirmed transactions. A feed may lose an attempt through replacement, eviction, restart or incomplete coverage. Absence from a later snapshot is not sufficient to identify the cause. Use an unresolved status unless the source supports a specific transition.
Hypothetical three-version payment
Assume a fictional wallet broadcasts A, B and C, each spending the same 1 BTC outpoint. A proposes 0.8 BTC to a recipient and pays a 0.0001 BTC fee. B keeps that payment but raises the fee to 0.0002 BTC. C raises it to 0.0003 BTC. Corresponding change adjusts to make the inputs and outputs reconcile.
| Observation | Attempts seen | Conflict family | Confirmed payments |
|---|---|---|---|
| A enters the feed | 1 | 1 | 0 |
| B and C appear | 3 | 1 | 0 |
| C confirms | 3 | 1 | 1 |
If C confirms with the stated recipient amount, the confirmed payment is 0.8 BTC, not 2.4 BTC from adding the three proposed payments. The confirmed fee is C’s fee; adding all three fees would also misstate settled fees. However, three attempts remain a valid operational statistic for the observed feed.
Now assume B changed the recipient. The family no longer demonstrates three versions of an identical payment instruction. A payment-intent series must distinguish changed intent from a simple fee adjustment or acknowledge that intent is unknown. The shared-input relationship establishes conflict, not motivation.
Keep relay evidence separate from chain evidence
Store when each node saw an attempt and whether the node reported its removal. Different nodes may see different replacements or descendants. A global “first seen” claim requires coverage beyond a single node. During outages, mark the feed gap rather than pretending no attempts occurred.
After confirmation, inspect the selected block and confirm which inputs were consumed. If the chosen chain later changes, revise the outcome under the published chain convention while retaining the observation history. A family with no known confirmed member remains unresolved; it should not automatically be called abandoned, fraudulent or failed demand.
Use matched windows when measuring replacement frequency. Dividing attempts arriving today by transactions confirming today mixes populations when confirmation is delayed. Prefer a first-seen cohort followed to a stated cutoff, showing pending families and the fraction with incomplete follow-up.
The deliverable is an attempt-to-outcome ledger, not instructions to replace a payment. It can explain why mempool counts rise without a corresponding increase in settled payments. It cannot establish total network demand, customer identity, or intent from transaction hashes alone.
Keep replacement relationships distinct from descendants. A transaction spending an unconfirmed parent’s new output is a dependent child, not necessarily a competing replacement. Counting both types as conflicts would wrongly merge valid chains of payments. Inspect whether transactions share a previous outpoint or instead create and consume successive outpoints before building the graph.
FAQ
Are three transaction identifiers always three payments?
No. If they compete for the same input, at most one can consume it on the selected chain. Keep attempts and settlement counts separate.
Does disappearance from my node prove replacement?
No. Eviction, restart, confirmation and missing observation can also explain disappearance. Record a specific reason only when supported.