PaperlayerView exact revision on arXiv

Source-linked AI summary

How Bitcoin Forms Its Network: Peer-Table Sampling and Structural Properties

Taki E. M. Abedesselam, Antonio Cruciani, Fabio Giacomelli, Lucianna Kiffer, Francesco Pasquale

arXiv:2609.07609v1cs.NIcs.SI

TL;DR

Because nodes know only their neighbors, the global network structure is hidden. The authors analyze Bitcoin and Dogecoin crawls and simulate Bitcoin’s formation protocol; the simulation shows that the network remains highly connected despite structural skew.

  • Problem

    Because nodes know only neighbors, the global structure is hidden, while uniformly random neighbor choice is costly to approximate with continuously running crawlers.

    Source: §1 · p. 2

  • Method

    The authors analyze six months of Bitcoin and Dogecoin crawl data to estimate size, churn, and visibility, then tune a Bitcoin-core formation simulator to study topology.

    Source: §5 · p. 12

  • Results

    Despite core-periphery skew, the giant component averages 99.72% of nodes and diameter stays 5; peer tables average 49,739 new entries, but only 17.2% match nodes alive at measurement.

    Source: §4.2 · pp. 9, 11

  • Takeaways & Limitations

    Crawl measurements and simulation together expose otherwise unobservable aspects of Bitcoin peer discovery, including peer-table contents and global topology.

    Source: §5 · p. 12

    The Bitcoin simulation models temporary departures as rejoining with probability q, retaining node identity and address tables.

    Source: §4.1 · p. 7

Abstract

from arXiv · show

The global structure of P2P networks underlying modern cryptocurrencies is hidden by design: each node only knows its neighbors and maintains a local \textit{peer table} of IP addresses. The peer table of a node can be seen as the node's ``local view'' of the set of nodes currently in the network: it is constantly updated with information collected from the neighbors and it is used by the node to establish new connections when needed. The maintenance rules of the nodes' peer tables determine the global structure of the network and its evolution. Even though the global structure is unknown to any node of the network as well as to any external observer, the rules for the exchange of information between neighbors are compatible with the design and use of network \textit{crawlers} that can query the nodes and extract some information about their peer tables. In this paper we first analyze the data we crawled from nodes of the Bitcoin and Dogecoin P2P networks, to collect information about the distribution of IP addresses in the peer tables and to estimate the evolution of network size and churn rate; we then use the estimates to set up the parameters for a simulation of the Bitcoin network and we analyze the evolution of the network structure that we get from the simulation. Overall, our results show that Bitcoin's peer-table maintenance rules induce non-uniform, heavy-tailed visibility patterns while nevertheless generating a well-connected and structurally robust network.

1 Introduction

The paper combines crawl-based measurements of Bitcoin and Dogecoin with a Bitcoin network simulator to examine how peer-table rules shape address visibility and network structure. It reports heavy-tailed address visibility alongside a highly connected, robust simulated network.

1 Introduction

  • Peer tables provide only local views, so the global network structure remains unknown and can be inferred only from partially disclosed addresses.Maintaining up-to-date information about all nodes is costly and only approximate.Source: §1 · pp. 1–2

1.1 Our contribution

  • Crawls of Bitcoin and Dogecoin find heavy-tailed address frequencies and approximately 5% daily churn in both networks.The study estimates approximately 10K reachable Bitcoin nodes and 600 Dogecoin nodes.Source: §1.1 · p. 2
  • The Bitcoin simulator reproduces heavy-tailed peer-table address frequencies and yields a highly connected network with a small diameter and spectral gap of approximately 0.5.Because simulated nodes use the same software and default parameters, the authors attribute the heavy tail to protocol peer-selection and maintenance mechanisms rather than heterogeneous node activity.Source: §1.1 · p. 2

1.2 Related work

  • Earlier measurement studies inferred topology from reachable peers and advertised addresses but did not explicitly analyze peer-table sampling biases; this paper addresses that gap.Related work on membership protocols also leaves dependencies between different nodes’ samples uncharacterized.Source: §1.2 · p. 3

1.3 Organization of the paper

  • The paper first presents Bitcoin-core network formation, then analyzes Bitcoin and Dogecoin crawl data, and finally describes and evaluates a Bitcoin-core-based simulator.Dogecoin is presented as a comparison network that implements the same peer-discovery protocol at roughly an order of magnitude smaller scale.Source: §1.2 · p. 2, §1.3 · p. 3

2 Bitcoin-core network formation primer

The primer describes how Bitcoin-core bootstraps peer tables, chooses outbound connections, and exchanges addresses. Its mechanisms include randomized storage and selection, network-group diversity, and both pull- and push-based address sharing.

2 Bitcoin-core network formation primer

  • AddrMan stores successfully contacted addresses in vvTried and other known addresses in vvNew, assigning entries using a salted cryptographic hash to make their positions unpredictable.vvTried has 256 buckets of 64 entries and vvNew has 1024 buckets of 64 entries.Source: §2 · p. 4

2.1 Bootstrap

  • A new Bitcoin-core node queries DNS seeds, inserts at most 32 addresses per seed into vvNew, and falls back to fixed seeds if the table remains empty.The node then attempts connections from vvNew.Source: §2.1 · p. 4
  • Operators can bypass DNS bootstrapping with -connect, which disables peer discovery, or use -addnode to add persistent peers while keeping discovery enabled..Source: §2.1 · p. 4

2.2 New connections

  • The default configuration allows up to 125 connections, including ten outbound connections: eight full-relay and two block-relay connections.Full-relay connections exchange blocks, addresses, and transactions; block-relay connections exchange blocks only.Source: §2.2 · p. 4
  • When both tables are populated, AddrMan selects vvNew or vvTried equally, samples a bucket and position, and applies a filter against outbound peers in the same network group.Recent Bitcoin-core versions define a network group by Autonomous System; connection failures and recent attempts also reduce candidate acceptance probability.Source: §2.2 · p. 4

2.3 Peer discovery

  • After an outgoing connection, a node sends GETADDR; its periodically refreshed cache contains a random address sample and is served unchanged to inbound requesters during its lifetime.A node answers only once per connection and ignores requests on connections it initiated.Source: §2.3 · p. 5
  • Nodes also push addresses through periodic ADDR messages, while token limits regulate processing and relay rules restrict which addresses are forwarded.Eligible addresses are relayed to selected neighbors, with per-neighbor filtering to prevent repeated announcements from increasing propagation.Source: §2.3 · p. 5

3 Empirical analysis

The empirical analysis uses daily Bitcoin and Dogecoin crawls to estimate network size and churn, then examines node availability and sampled peer-table addresses. It uses the measurements to parameterize simulations and compare address visibility with simulated results.

3 Empirical analysis

  • Daily crawls from two three-month periods support estimates of network size and churn and provide an empirical baseline for peer-table properties.The periods are July–September 2025 and February–April 2026.Source: §3 · p. 5

3.1 Network size and churn

  • Bitcoin has a median of approximately 10,000–10,700 active nodes per day, compared with approximately 590–650 for Dogecoin, and both counts are similar across periods six months apart.Active nodes responded to at least one in-protocol PING; the study uses crawl measurements to inform the simulation’s churn model.Source: §3.1 · pp. 5–6
  • Approximately 20% of nodes remain active throughout the observation window, while most exhibit intermittent participation.Uptime is measured as the total number of days each node is observed active.Source: §3.1 · p. 6
  • The study treats absences of up to one day as within a session and defines churn as absence for at least two consecutive days after a node was active.Most nodes appear in one session, and inter-session gaps are concentrated at one day; the authors suggest brief gaps may reflect measurement artifacts or transient interruptions.Source: §3.1 · p. 6

3.2 Peer table sampling and address visibility

  • GETADDR responses provide partial peer-table samples; the analysis filters responses with at least 800 addresses, pools samples by measurement period, and counts each address’s appearances.The method treats each response as an independent sample of up to 1,000 addresses.Source: §3.2 · pp. 6–7

4 Simulations

The Bitcoin Core-default simulator uses crawl-derived churn estimates to examine peer-table contents and network structure. It finds that address tables are dominated by unusable addresses even as the network remains highly connected.

4.1 Network Model

  • The Bitcoin Core-default simulation matches crawl-derived churn; instruments record full address managers and daily caches, while a virtual crawler samples reachable-node caches.The model includes temporary departures that may return with the same identity, reachability and address-grouping assumptions, and outbound full-relay connections.Source: §4.1 · pp. 7–8, §4.2 · p. 8

4.2 Simulation Results

  • Only 2.4% of peer-table entries had ever connected successfully and 17.2% belonged to a node alive at measurement; most never-active entries were expired addresses of unreachable nodes.Tables averaged 49,739 new-table entries and 1,215 tried-table entries; cached addresses averaged 9.6 days old, yet unusable entries persisted as new dead addresses arrived faster than cleanup removed them.Source: §4.2 · p. 9
  • By day 119, 289,377 daily discovered addresses contrasted with 33,655 live nodes (8.6 per node) and 5,660 reachable nodes (51 per node), while circulating addresses kept growing.The total discovered set reached 913,079 distinct addresses over the window.Source: Figure 4 · p. 9, §4.2 · p. 9
  • Cached-address live-node share fell from 45.3% on day 13 to 11.6% on day 119 as rotating unreachable addresses diluted stable reachable addresses.The figure distinguishes cache coverage against all nodes alive during the day from coverage against the end-of-day snapshot, and peer-table accuracy against that snapshot.Source: Figure 5 · p. 10, §4.2 · p. 10
  • Active addresses were 4.9 times more visible at the median, but the crawl's barely visible reservoir was not reproduced: 24.8% of addresses appeared in at most two responses versus 0.12% in simulation.The authors suggest omitted node heterogeneity or address histories longer than the simulated window may explain the gap; feeler success also fell from 15.6% to 5.4%.Source: §4.2 · p. 10
  • Reachable addresses appeared in about 2.2 times as many caches as the average address, consistent with successful connection verification promoting them to the tried table.Reachable addresses were 5.8% of those present on a typical day; their visibility distribution peaked near 500 caches, versus near 40 for all addresses.Source: §4.2 · p. 10
  • Unreachable nodes had degree 8 in 99.97% of cases; reachable nodes ranged from degree 8 to 125 (median 39, mean 51.7) with a bimodal distribution.The figure omits unreachable nodes and shows the reachable-node distribution averaged over days 13–119.Source: Figure 6 · p. 11, §4.2 · p. 11
  • The giant component averaged 99.72% of nodes and the estimated diameter stayed at 5 despite a growing unreachable periphery and increasingly disassortative structure.The degree assortativity coefficient fell from −0.412 on day 13 to −0.569 on day 119; recently verified addresses bias connection formation and help preserve connectivity.Source: §4.2 · p. 11

5 Conclusions

The paper combines crawl-based empirical analysis of Bitcoin and Dogecoin with a Bitcoin Core network-formation simulator. The crawl estimates network size, churn, and address visibility, while simulation examines peer-table dynamics and global structure not observable through measurement alone.

5 Conclusions

  • Crawl analysis estimates network size, churn rate, and address visibility patterns in Bitcoin and Dogecoin.The conclusions describe these estimates as derived from the data available to network crawlers.Source: §5 · p. 12
  • A Bitcoin Core network-formation simulator is tuned using crawled data to study peer-table dynamics and the evolving global topology.The simulation is used to examine aspects of peer discovery not observable by measurement, including the nature of peer-table addresses and the gap between discovered addresses and active nodes.Source: §5 · p. 12
  • The study combines six months of crawl data from Bitcoin and Dogecoin with simulation of Bitcoin's network-formation protocol.Source: §5 · p. 12

A.1 Data collection and observables

The data collection uses daily crawls that query nodes' peer tables and track address observations and availability. It distinguishes nodes that return crawl data from those that respond to protocol-level PINGs.

A.1 Data collection and observables

  • Daily crawls query participating Bitcoin and Dogecoin nodes using the standard peer-discovery protocol.The study collects data over two three-month periods.Source: §A.1 · p. 14
  • A crawler requests peer-table samples, and nodes return random subsets of entries in ADDR messages, up to 1,000 addresses.Repeated responses from the same node provide approximately independent samples of its local view over time.Source: §A.1 · p. 14
  • Daily records include crawled nodes, sampled peer addresses, their unique-address union, and the subset responding to in-protocol PINGs.PING responsiveness is used as a coarse availability indicator.Source: §A.1 · p. 14
  • PING-responsive nodes may include nodes that do not return ADDR data, so crawled and PING-responsive participation are tracked separately.Source: §A.1 · p. 14
  • Addresses are analyzed as unique IPs or IP:port pairs, with IPv4 and IPv6 included and observations merged across days.Source: §A.1 · p. 14

A.2 Network size and session structure

Across two measurement periods, Bitcoin has substantially more active nodes and discovered addresses than Dogecoin, with network size and churn metrics consistent between periods. Most observed nodes appear in one session, and a one-day absence underlies the study's churn grace period.

A.2 Network size and session structure

  • Bitcoin has a median of over 10,000 active nodes per day and over one million unique addresses discovered per three-month period, while Dogecoin has about 590–650 active nodes per day.Source: §A.2 · p. 14
  • Key scale and churn metrics are consistent across periods approximately six months apart, indicating both networks are in a stable regime.Source: §A.2 · p. 14
  • Most nodes appear in a single uninterrupted session; among nodes with multiple sessions, gaps are almost always exactly one day.Source: §A.2 · p. 14
  • The one-day gap pattern motivates treating single-day absences as within-session rather than genuine departures when defining churn.Source: §A.2 · p. 14

A.3 Data cleaning and preprocessing

The preprocessing retains IP:port as the node identifier after checking response distinctness across ports on the same IP. It also restricts analysis to large ADDR responses and reports daily active and discovered counts using logarithmic-scale plots.

A.3 Data cleaning and preprocessing

  • 99.5% of 664,904 Bitcoin responses in Jul–Sep 2025 and 99.2% of 702,587 in Feb–Apr 2026 were unique, supporting IP:port as the node identifier.Uniqueness was also 98.1% of 5,889 Dogecoin responses in Jul–Sep 2025 and 97.3% of 6,303 in Feb–Apr 2026; the analysis retains purely unique responses per IP:port.Source: §A.3 · pp. 14–15
  • Figure 7 plots daily discovered and active IP:port counts for Bitcoin and Dogecoin on a logarithmic y-axis.Discovered counts are the daily union of peer-table entries; active counts are addresses responding to at least one in-protocol PING.Source: Figure 7 · p. 15
  • Table 1 summarizes daily and period-total active and discovered counts, IPv6 fractions, and mean daily churn across identity models and measurement periods.Churn uses a one-day grace period, and reported values are consistent across periods and close to 0.05.Source: Table 1 · p. 15
  • Approximately 65–70% of Bitcoin ADDR responses reach the 1,000-address protocol maximum; analysis retains responses containing at least 800 addresses.The threshold retains 76.8% and 69.3% of Bitcoin responses across the two periods, and 93.7% and 91.2% of Dogecoin responses.Source: §A.3 · pp. 15–16

B.1 The all reachable baseline

The all-reachable baseline provides a comparison for separating effects of unreachable peers from network scale and maturation. At day 118, the reachable core of the mixed network matches the baseline in assortativity, while its address-table balance differs; baseline readings persist to day 704.

B.1 The all reachable baseline

  • The baseline run targets 10,000 nodes, stabilizes at approximately 10,079 live nodes, and has daily churn of 5.3%.It runs for 704 simulated days with every joining node accepting inbound connections.Source: §B.1 · p. 16
  • At day 118, degree assortativity is +0.055 in the baseline and +0.056 in the mixed network’s reachable subgraph, versus −0.569 in the full mixed graph.The baseline remains between +0.05 and +0.06 through day 704.Source: §B.1 · p. 16
  • Most nodes participate in one continuous session; multi-session gaps cluster at one day, suggesting transient measurement artifacts rather than genuine departures.Source: Figure 8 · p. 16
  • Bitcoin crawl responses concentrate at the 1,000-address protocol maximum, with approximately 65–70% reaching it in both periods; Dogecoin responses are more variable at 60–80%.The more recent Dogecoin period trends toward smaller responses, likely reflecting a growing share of non-IPv4/IPv6 nodes.Source: Figure 9 · p. 17
  • The baseline’s tried table holds 29.6% of capacity versus 18.8% in its new table, while the mixed run reverses the ordering to 7.5% and 76.1%.Baseline cached-to-live ratio shifts from 2.20 at day 118 to 2.18 at day 704, and coverage from 45.4% to 46.0%.Source: §B.1 · p. 17

B.2 Where the inbound load goes

Unreachable peers concentrate inbound connections on the reachable core because every node opens eight outbound connections while unreachable nodes accept none. Long-lived reachable nodes accumulate especially high degree, unlike nodes in the all-reachable baseline.

B.2 Where the inbound load goes

  • All 8 × 27,986 ≈ 224,000 outbound connections from the periphery terminate on 5,669 reachable nodes, yielding about 39 inbound connections each.Together with their own eight outbound and roughly eight inbound connections from other reachable nodes, this accounts for mean reachable degree 51.7.Source: §B.2 · p. 17
  • Long-lived reachable nodes accumulate inbound connections during their sessions, producing a second degree mode at the connection limit of 125.Source: §B.2 · p. 17
  • In the baseline, inbound connections are spread across the population, with mean inbound degree eight and daily maximum degree near 42; no node approaches the limit.Source: §B.2 · p. 17

B.3 Supplementary figures

The supplementary figures show that reachable addresses are disproportionately represented in caches, especially over a month, and that the reachable core retains distinct structural properties. They also identify the protocol telemetry and simulation comparison measures.

B.3 Supplementary figures

  • Over the trailing 30 days, reachable addresses appear in 3.9 times as many caches as the median address—4,464 versus 1,134—and make up 89.4% of the most visible percentile.They are 4.1% of the population and account for 14.7% of all appearances; 1,256 addresses, 0.22% of the total, are held in almost every cache, and all are reachable.Source: §B.3 · pp. 17–19
  • Table 2 compares the two simulations at day 118, including the mixed network’s reachable-node subgraph; baseline values persist essentially unchanged through day 704.Address-level quantities apply to the whole population and are not repeated for the subgraph.Source: Table 2 · p. 18
  • In the simulated address-visibility CCDF, active addresses are systematically more visible than the full population, matching Figure 3’s qualitative structure.The plot pools 575,609 full-size responses from days 28 to 120.Source: Figure 10 · p. 18
  • Figure 11 compares degree assortativity over time for the all-reachable baseline, the mixed network, and the mixed network’s reachable-node subgraph; the mixed graph reaches −0.57 under its degree-eight periphery.The core tracks the baseline across their overlapping window.Source: Figure 11 · p. 19
  • Figure 12 tracks feeler success, GETADDR responses served, and unsolicited addresses discarded by the token bucket over days 7–119 of the mixed run.Source: Figure 12 · p. 20
  • On a single day, reachable-node addresses are carried in about 2.2 times as many caches as the curve for all cached addresses.Source: Figure 13 · p. 20
Loading 2609.07609v1…