To have data for a simulation, I’ve been looking at the rate of successful outbound connections my nodes are making. I’m parsing and using the following log messages for this:
New CONN_TYPE peer connected: transport: TRANSPORT, version: VERSION, peer=ID peeraddr=ADDR: tells us about a successful block-relay-only or outbound-full-relay connection. This is also logged for inbound connections when net-logging is enabled, but we ignore this here.
feeler connection completed, disconnecting peer=ID, peeraddr=ADDR tells us about a feeler connection finishing
I’m only looking at these connection types for now:
outbound-full-relay (normal outbounds)
block-relay-only (outbound, but only relaying blocks)
feeler (to check if an address is reachable)
I have data from multiple peer.observer nodes that run with different configurations.
I’ll split this up into multiple posts so it’s easier to link to a specific one or reply to a specific one.
Before looking at connection success rates, it makes sense to look at outbound connection attempts per time. All of the following plots show attempts-per-hour averaged over a day or a week.
Generally, my nodes all make ~57 outbound connections per hour. So close to one per minute. Node jade differs here, it makes ~43 per hour. I haven’t looked into why yet. The number of outbound attempts per hour seems to be stable since the start of my data in 2024.
We can also split these 57 connections per hour up by network we are connecting to. Note that the nodes can reach ( ) different networks. Some nodes might try to connect to e.g. IPv6, while they’ll never be able to make a connection ( ).
For IPv4, alice, bob, charlie, frank, and ian make about 37 connection attempts per hour. Both dave and jade, who can reach more network, make fewer connections (about 27) to IPv4 per hour.
For IPv6, alice, bob, charlie, frank, and ian make about 17 connection attempts per hour. The node dave, which can’t reach IPv6 (but can reach Tor and I2P), makes about 15 connections to IPv6. Since none of these nodes can reach IPv6, all these connections are going to fail. However, node jade can actually reach IPv6 and makes about 5 connection attempts per hour.
For I2P, which both dave and jade can reach, they make about 2 connections per hour.
To summarize, the nodes make the following number of connections per hour to:
Node
IPv4
IPv6
Tor
I2P
alice
37
17
-
-
alice
37
17
-
-
alice
37
17
-
-
dave
27
15
12.5
2
alice
37
17
-
-
jade
27
5
12.5
2
alice
37
17
-
-
This explains why jade is making fewer connections per hour (about 43 vs about 57): jade is the only one that can reach IPv6 nodes. Once it has IPv6 connections, it does not need to retry connecting to IPv6 too often.
Connection attempts are likely affected by outbound connection churn (how often the connection to our outbounds drop) and our address manager composition. These numbers might be different on nodes configured differently.
By network and connection type
Looking at the number of attempts node alice makes by network and connection type shows that about 25 attempts per hour are IPv4 feeler while only 5 attempts are IPv6 feeler. About 12.5 attempts are IPv6 outbound-full-relay (which all fail), while it’s only 2-3 IPv4 outbound-full-relay attempts per hour (out of which some succeed). For block-relay-only connections, it’s the other way around: Alice only makes about 2 block-relay-only IPv6 connections per hour, while it makes 12.5 block-relay-only IPv4 connections per hour.
Knowing about the differences between the node configurations and the number of outbound connection attempts allows us to better understand the success rates of these attempts.
The nodes alice, bob, charlie, frank, and ian all have a similar success rate of 12% - 15%. Out of 57 attempts per hour, that’s about 8 new outbound connections (feeler included) per hour. Dave, which is also able to connect to Tor and I2P, has a higher success rate at 30% in median. Jade, which can also connect to IPv6, is closer to a median of 40% success. To better understand this, we can drill down by network and connection type.
By network
All nodes can make connections via IPv4. Between 2025-01 and 2025-03-31, the nodes averaged at about a 20% (or slightly more) connection success rate. Since 2025-04, when bitprojects ( Many connections to bitproject.io nodes? - #24 by bitprojects ) shut down their nodes, we’ve been seeing it dip below 20%. It’s closer to 15% now.
For all three nodes, the outbound-full-relay connections have a success rate of about 5%. On alice and frank, who can both only connect to IPv4, this matches with the feeler connections. However, on dave, the feeler connections have a much higher success rate at above 30%. On explanation for this is the high Tor and I2P success rate we’ve seen on dave. However, block-relay-only connections have a much higher success rate than the outbound-full-relay we are making. For alice and frank, about 20%-30%, and for dave about 40%.
At first, this was confusing to me: block-relay-only connection success rates should not differ so much from outbound-full-relay success rates, as we select from the address manager tried table for both (as opposed to selecting from the new table for feelers).
By network and connection type
Looking at, for example, the success rate of alice’s IPv4 connections, shows that both block-relay-only and outbound-full-relay connections share the same ~25% percent success rate. At the same time, feelers are only successful at less than 10% of the cases in early April 2026 and less than 5% successful in June 2026 (I suspect this is related to the ongoing address message spam covered in /python-bitcoinlib:0.12.2/ client getting addr-ratelimited (since 2026-04-10) - #6 by b10c ).
All attempts of alice to connect to IPv6 fail (not shown here). This helps to explain why the success rate of block-only and full-relay connections differ:
As discussed in Outbound connection success rates of a Bitcoin node - #2 by b10c , Alice makes about 3 IPv4 full-relay attempts at a ~25% success rate. It also makes 12.5 IPv6 block-relay-only connections to IPv6 with a 0% success rate. This means, maybe 3/4 out of 15.5 (or about 5%) of outbound-full-relay attempts succeed.
For block-relay-only, it’s 12.5 IPv4 attempts per hour with the same 25% success rate, and 3 IPv6 attempts per hour that always fail. That’s 3,125 connections per 15.5 block-relay-only attempts that succeed (or about 20%).
Both of these match what we’ve seen before in the “By connection type” section during the last few months.
For the simulation, we are primarily looking for a realistic success rate of IPv4 and IPv6 connections. This allows us to simulate a node picking an address, “attempting” a connection to it, and then either succeeding or failing. When we fail, we “attempt“ another connection. Additionally, we want a success rate that ignores feelers, as feelers are only made to connections from the addrman new table (addresses we’ve never tried before). These are expected to be worse than connections to the tried table (addresses we’ve tried before).
For IPv4, we have this data from node Alice, which generally seems to perform very similar to the other nodes:
We can probably get close to reality assuming a 25% connection attempt success rate for IPv4.
For the simulation, it’s also important to know how frequently connections to Bitprojects ( Many connections to bitproject.io nodes? - #19 by b10c ) were attempted and how often they succeeded. If, for example, all attempted connections to Bitprojects succeeded, then we can assume that once we picked a Bitprojects address from our address manager, we also made a connection to it.
In the final months before it was shut down, Bitprojects was using 12x /24 IPv4 ranges with each of these 3072 IPs having some kind of reachable Bitcoin node behind it. My nodes first started making connections to it in mid July 2024. This grew to about 0.75 outbound connections per hour per node in April 2025. In October 2025, this started to increase and by January 2026, some of my nodes were making 2 outbound connections per hour to Bitprojects IPs. But how many of these connections were successful?
When Bitprojects initially started in mid 2024, connectivity to it wasn’t good. Until early 2025, usually less than half of the connections my nodes attempted to Bitprojects succeeded. This changed in early 2025. Then, nearly all connections succeeded. There still was some downtime here and there, but for many of my nodes, there were multiple weeks with high success rates. Around October 2025, connectivity dropped nearly completely, which is likely related to the clock misconfiguration Antoine discusses in Antoine Poinsot - Misbehaving nodes investigation and the Bitprojects maintainer pausing and then re-enabling the nodes. From then on, connectivity remained very high until the nodes were stopped at the end of March 2026.
While Bitprojects used 12x /24 IPv4 subnets at the end, they started with the first /24 in mind July 2024. In October, November, and December 2024, they added three more /24’s. In October 2025, they added eight more /24’s.
Bitcoin Core v26.0 (released November 2023) introduced experimental support for BIP324 v2 transport, but it was off by default and had to be enabled manually using the -v2transport option. It was enabled by default in Bitcoin Core v27.0, which was released in April 2024. In June 2026, more than 80% of the outbound connection attempts my nodes make are to v2 nodes.
It can happen, that we try to make a v2 connection to a node which does not support v2 transport. For example, when we store an address with the service flag `NODE_P2P_V2` set in our address manager, because we received it this way through address gossip. We’ll attempt a v2 connection, but downgrade to v1 if we can connect, but can not establish a v2 connection.
My nodes downgrade from v2 → v1 transport for about 30 to 40 connections per day. Depending on node, they have between 200 and 400 successful connection attempts per day. This means, we have a v2 → downgrade rate somewhere between 15% and 20%. Most of these seem to be feeler connections. This is expected, as we’re using information from the new table for feelers. In the tried table, we’ve updated potential service flag mismatches after a first connection.
I haven’t used any ASmap information yet for this. Anything you are curious about?
I’ve seen a lot of connection attempts to AS56047 (China Mobile Communications Corporation) on different IPv4 subnets. This might be interesting to look into further. Having AS information would allow to find other Bitprojects-like entities easier in this data.
I’m curious to know if ASmap is behaving as intended and whether certain AS are more likely to encounter connection issues. There are probably more interesting considerations, but I’m not very creative.
) different networks. Some nodes might try to connect to e.g. IPv6, while they’ll never be able to make a connection ( 
).
