Note: This was originally published to the Bitcoin Development mailing list.

tl;dr: By connecting to every Bitcoin Core v24 node I could, and measuring transaction invs, I determined that at this moment about 17% of all Bitcoin Core v24 nodes listening on IPv4 are running with full-rbf enabled and successfully propagating full-rbf replacements.

Procedure

  1. Modify MAX_ADDNODE_CONNECTIONS to 5000 and recompile.
  2. Run ./bitcoind -mempoolfullrbf=0 -debug=inv -debug=mempool -debug=mempoolrej
  3. Manually addnode every IPv4 address of a node matching Satoshi:24 and not advertising the full-rbf service bit in my DNS seed’s dnsseed.dump file. This happened to be 692 IPv4 addresses.
  4. Wait for connection counts to stabilize. I managed to connect to ~500 nodes out of the 692 I tried connecting too.
  5. Wait for one of my OpenTimestamps calendars to perform a full-rbf replacement1. They wait a significant amount of time (60s) between transactions and blocks to ensure good propagation, and a true full-rbf replacement.
  6. Wait 2 minutes to ensure complete propagation of the replacement transaction.
  7. Run grep <wtxid> ~/.bitcoin/debug.log | grep 'got inv' | wc -l to count the number of invs. (I obtained the wtid from another node running full-rbf)
  8. Repeat steps 4 to 6 three more times to verify counts are stable.

Discussion

This data shows substantial adoption of the mempoolfullrbf=1 option among IPv4 listening nodes, above and beyond people choosing to run Bitcoin Knots or another full-rbf peering fork of Bitcoin Core. This data is also an underestimate: I’m only measuring successful propagation. Nodes which have full-rbf enabled — but do not have any full-rbf peers — are not counted by this measurement. Thus the true number of full-rbf nodes will be even higher than these stats indicate.

Since v24 nodes are currently only ~5% of all listening nodes, the probability2 of a non-listening node having a full-rbf peer in their outgoing 8 connections is still low, ~8%. However, if this 17% was maintained as all nodes eventually upgrade to v24, the probability of a full-rbf peer in the outgoing 8 would be quite high, ~80%.

Future Work

How are full-rbf nodes distributed among the IPv4 address space? Bitcoin Core, by default, groups IPv4 addresses into /16 buckets, and does not connect to more than 1 outgoing node per bucket. The true probability of connecting to a full-rbf peer may be changed by this distribution.

How are full-rbf nodes distributed among other connection types? At the moment bitnodes.io reports that a majority of listening nodes are listening on .onion addresses. Due to the difficulty of connecting to very large numbers of Tor nodes at once, and a lack of a convenient source of onion addresses to try, I did not attempt to measure full-rbf adoption among onion nodes. IIUC a number of pre-built “node in a box” solutions such as the Start9 Labs Embassy are currently only able to listen via Tor.

How are full-rbf nodes distributed among non-listening nodes? A potential strategy to measure this could be to measure invs on a listening node with a large number of incoming peers. Anecdotally, I have been told by a number of people that they’re running mempoolfullrbf=1 on non-listening nodes.

Footnotes

  1. My OpenTimestamps calendars, Alice and Bob are currently doing full-rbf replacements ↩

  2. Suppose there are \(N\) potential outgoing peers, \(M\) of which run full-rbf. That means the probability of any one outgoing peer running full-rbf is \((1-\frac{M}{N})\), and thus the probability of all $8$ outgoing peers not running full-rbf is \((1-\frac{M}{N})^8\). ↩