Note: This was originally published to the Bitcoin Development mailing list; reprinted below with an important correction.

Since Anthony Towns criticized my use of OTS1 to measure full-RBF adoption, I’ve been doing high-fee full-RBF testing to re-confirm my findings. Specifically, that means sending a high fee tx1 with a fee more than sufficient to get mined in the next block. Then 30 seconds later, I send tx2, a double spend with an even higher fee, removing one of tx1’s outputs. Propagation was verified for each full-RBF double-spend by checking debug.log on another very well-connected node.

Results: >31% of hash power, over at least 4 different pools, is mining full-RBF at the moment, assuming Binance Pool is mining full-RBF with half their hashing power (see below for details). This finding confirms my OTS calendar research, which found similar results.

Specifically, in my testing yesterday I successfully did the following full-RBF double-spends:

Antpool: 2ebe68edca320dabdd8b39ebae5f18efaac829055058a2c0f4bc2b37c69cd88c
Poolin: 68ca9ee95748dc98ba24018ea64c18de31fca552e4753ef012acd0b615cd7384
EMCDPool: dde0975ad42fd9e03677f64b6c4f7efbe2ec0b6f905206d47893a77ac6336fca
Binance Pool: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5

Anyone running a full-RBF node with debug=mempool can easily verify all these double-spends by examining their debug.log files.

With Antpool, Poolin, and EMCDPool, it is most likely that they’re mining full-RBF with ~100% of their hash power. These pools mined every double-spend available to them, with the exception of some Antpool blocks found very close to when the double-spend was broadcast. Binance Pool did not mine a full-RBF replacement on two occasions, which makes me suspect they’re mining full-RBF with less than 100% of their hash power. During this testing, Binance Pool, AntPool, Poolin, and EMCDPool, also all mined multiple double-spends from my OTS calendars, further confirming my findings.

My OTS research also found examples of KuCoinPool and ULTIMUSPOOL mining full-RBF double spends. They didn’t find any blocks during this testing, so I have no data on them with this testing. Luxor did mine some blocks without mining the double-spends, so at the moment it’s reasonable to assume they have full-RBF fully or partially disabled, or have some kind of full-RBF propagation issue. They have confirmed similar issues to me in the past (eg employees unintentionally disabling it on some nodes during an upgrade), so it’s likely that has happened again. MARA Pool also mined some blocks without mining double-spends, so they too may have full-RBF fully or partially disabled, as I mentioned in my OTS research.2

The tool I used is my script. Note that this script was written years ago, pre-segwit, and I hastily updated it for recent Bitcoin Core/python-bitcoinlib versions. I haven’t checked if all the options like OP_Return outputs and multisig still work, and it doesn’t even take segwit into account when calculating fees. Don’t use it on a wallet with funds you can’t afford to lose; it definitely has bugs in it.

For reference, here is the logs from a successful double-spend attempt:

    $ sleep 15 ; ./ --fee1 0.00018 --fee2 0.000224 `/home/user/bitcoin/src/bitcoin-cli getnewaddress` 0.00001
    DEBUG:root:Delta fee: 0.00002296
    DEBUG:root:Adding new input caec040f4435e98de9ae44a385e301312c5a3cddfb33f1bd08e1cf63307f87ce:0 with value 0.00072549 BTC
    DEBUG:root:Delta fee: 0.00003035
    DEBUG:root:Payment tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff028a0f01000000000016 00149e12f3ef33ba4ccde4b85978e675c9fe59bb24a2e8030000000000001600149049e0f57ec5899c1eed2c5e9aab1c34ff5cec1f02473044022063834a187727c1eceb9b3e6ae9cc d0d369b51af3493fafba1d61ed3b273d48f7022049fbe71ecd600c7345fb6002e04275eb8445031df746eceaa6e6f5f413f67497012102c56d86e3031851822485d1a2f9f0e402f14b 96b64e711d5a2567412d1ea49a8b00000000
    INFO:root:Payment tx size: 0.222 KB, fees: 0.00002035, 0.00009166 BTC/KB
    INFO:root:Sent payment tx: 1c28870a78efd1c4616726ea0ca3f9d67f5591aab415222e2c9ec6184fc0b4f2
    INFO:root:Sleeping for 30 seconds
    DEBUG:root:Delta fee: 0.00004279
    DEBUG:root:Double-spend tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff01ae0a010000000 0001600149e12f3ef33ba4ccde4b85978e675c9fe59bb24a20247304402201289c26da70e9ec4424fc2ff7194b57384c78c9c986c2efe6771ac6f5fda199702200cefa72560f21cd9a be846078ce13197029562102f7a44b8ec50772a851c1799012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412d1ea49a8b00000000
    INFO:root:Double-spend tx size: 0.191 KB, fees: 0.00004279, 0.00022403 BTC/KB
    INFO:root:Sent double-spend tx: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5

Remember that if you want to replicate this, don’t be surprised if it takes quite a few attempts if you’re sending tx1 with next-block fees. A minority of hash power is mining full-RBF. There’s also a chance that in the ~30s or whatever you wait between tx1 and tx2, a block is found and tx1 gets mined. This chance is actually even higher than the ~5% you’d expect, because miners don’t instantly update their block templates.

So if ~30% of hash power is actively mining full-RBF, you might actually have a ~20% chance per attempt at succeeding at a naive high-fee/higher-fee double-spend. Thus there’s a:

\[(1-20\% )^{10} = 11\%\]

chance that 10 attempts in a row fail. Being that unlucky happens all the time; the Gods of Probability, probably hate you. :)

Finally, research like this is expensive in terms of my time and transaction fees; research via the OTS calendar approach is essentially free. Donations are appreciated as no-one is paying me to do full-RBF work or covering these expenses.

Cheapest/easiest way is via Lightning. Or on-chain: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv.