Feedback-ID: i525146e8:Fastmail
Date: Thu, 22 Dec 2022 22:06:03 -0500
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <Y6UbG4lcVaVmqdls@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="acKwH0Epq/OmGcsV"
Content-Disposition: inline
Subject: [bitcoin-dev] At least 17% of Bitcoin Core 24.x listening nodes are
 running full-rbf
Precedence: list


--acKwH0Epq/OmGcsV
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:

0) Modify MAX_ADDNODE_CONNECTIONS to 5000 and recompile.
1) Run ./bitcoind -mempoolfullrbf=3D0 -debug=3Dinv -debug=3Dmempool -debug=
=3Dmempoolrej
2) 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.dum=
p'
   file. This happened to be 692 IPv4 addresses.
3) Wait for connection counts to stabilize. I managed to connect to ~500 no=
des
   out of the 692 I tried connecting too.
4) Wait for one of my OpenTimestamps calendars to perform a full-rbf
   replacement=B9. They wait a significant amount of time (60s) between
   transactions and blocks to ensure good propagation, and a true full-rbf
   replacement.
5) Wait 2 minutes to ensure complete propagation of the replacement transac=
tion.
6) 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)
7) Repeat steps 4 to 6 three more times to verify counts are stable.


Discussion:

This data shows substantial adoption of the mempoolfullrbf=3D1 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 probabil=
ity=B2
of a non-listening node having a full-rbf peer in their outgoing 8 connecti=
ons
is still low, ~8%. However, if this 17% was maintained as all nodes eventua=
lly
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 conn=
ect
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 mom=
ent
bitnodes.io reports that a majority of listening nodes are listening on .on=
ion
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 numb=
er
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 inv's 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=3D1 on non-listening nodes.


References:

1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/02=
1143.html
2) https://stacker.news/items/98441

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--acKwH0Epq/OmGcsV
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmOlGxgACgkQLly11TVR
LzfsDQ//WziIMi5PORGhSMn5xeJ26WCXXRzEMBWRZLQ+QqSS6h/WeK88rhbYj3ox
3S1DPJXUCjNOXN5CBWkTYvLB6ZZbhaDF9hlQSZ+tfzZUP15k1vS33TVHoDrYxJss
zHrWLw7i/2yDFsx43BHDs7YipxuBZR/xF1TxCDIF5WTenv6MfA6o/pgPXH/6Aw+M
fgYM4xrkmL+gxW+7VdyrZlIYD9tCaH0GUs4+QKpi2ZkoL6ssv7vlNHKNT9yf974i
wDDTVoIrfD8oy1xVHrx5bUESVgdTxD4wai21HXSkeGUtfpSlJP5EJCrfXZJJfkIQ
8Xx8p2B34qIGPCaKeoEshU39kmImRGGuqsMXMmMzDfFjLXn2fkPHZTgDIsav6e9l
WU3IV0u1PZLtqys2vKrc4q4LbC9IEGvV8UNuhkSTClIzje8z0KXQUB69uUdLF5Iz
c4PdG3hjv7IxXOcuvMVFIEiRCzhBXcE+ZYPMuUJasuEnPAfmxuirVkqLMh9DkyVi
yBMQZ8H93sHQB6+6uHfGZ9wlVy2DCfk3KT7nlaoWtWgbQ4iCX04JOQ7TQvPMTxH5
t6m7kPJTeSKLH6IEfvwMtmn2F1DDcu9g1Lq8YSWvPcIvDJZy4B6NBLLpWCCktYvt
eU/swh3JfkbFye3S2/EZ8PPjzpZ1N1aNtK/FvXTlTvVZsFooRxs=
=2c0o
-----END PGP SIGNATURE-----

--acKwH0Epq/OmGcsV--