Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-23 📝 Original message:tl;dr: By connecting to ...
📅 Original date posted:2022-12-23
📝 Original message: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=0 -debug=inv -debug=mempool -debug=mempoolrej
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.dump'
file. This happened to be 692 IPv4 addresses.
3) Wait for connection counts to stabilize. I managed to connect to ~500 nodes
out of the 692 I tried connecting too.
4) Wait for one of my OpenTimestamps calendars to perform a full-rbf
replacement¹. 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 transaction.
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=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 probability²
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 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=1 on non-listening nodes.
References:
1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021143.html
2) https://stacker.news/items/98441
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221222/e8823a25/attachment.sig>;
📝 Original message: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=0 -debug=inv -debug=mempool -debug=mempoolrej
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.dump'
file. This happened to be 692 IPv4 addresses.
3) Wait for connection counts to stabilize. I managed to connect to ~500 nodes
out of the 692 I tried connecting too.
4) Wait for one of my OpenTimestamps calendars to perform a full-rbf
replacement¹. 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 transaction.
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=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 probability²
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 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=1 on non-listening nodes.
References:
1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021143.html
2) https://stacker.news/items/98441
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221222/e8823a25/attachment.sig>;