You install Bitcoin Core on a laptop and start it for the first time. The address book is empty. There is no account to open and no company server to call. The program holds seven host names written into its source code, each looked after by a named contributor, and from those it works its way to 10 outbound connections with machines it picked itself: 8 that relay everything and 2 that relay only blocks. Nobody assigned them. That is a peer-to-peer network in a blockchain at work, and the rest of this lesson follows the same three questions a new node faces: how to find strangers, how news crosses thousands of machines that do not trust each other, and what an attacker can do to that road.
The previous lesson covered what a node is and what it stores. Here the node is taken as given, and so is the chain it keeps (how a blockchain works and what is inside a block have their own lessons). This one stays on the wires between nodes.
What a peer-to-peer network in blockchain replaces
In a client-server system, your banking app talks to the bank. The server holds the data, decides who may enter and can be switched off by whoever runs it. In a peer-to-peer system each machine asks and answers. There is no privileged address, so there is no single place to knock on, and no single operator to take offline or to order about.
Two older systems show why the details matter. Napster moved music files directly between users, but, as the Ninth Circuit described it in February 2001, software on its own servers kept the search index of who had what, and those servers handed out the host’s internet address. That central piece made it easy to stop: a later ruling records that Napster disabled file transfers and that the district court ordered them kept off until it was satisfied. BitTorrent went further. Its trackers were still central, so BEP 5, by Andrew Loewenstern and Arvid Norberg, turned every participant into a small tracker through a Kademlia distributed hash table: 160-bit identifiers, XOR distance, buckets of 8 nodes and four query types.
Bitcoin’s whitepaper set a harder job than either: a “purely peer-to-peer version of electronic cash”. Sharing a song tolerates a dishonest peer, because the worst outcome is a bad file. Agreeing on who owns what does not. That is why a node checks everything it receives, and why the design described in the whitepaper asks so little of the network itself. Its section 5 says “New transaction broadcasts do not necessarily need to reach all nodes.” Messages can be late, lost or sent by liars, and the system still has to hold.
One limit on the word “open”: this lesson is about public chains, where anyone can join. Private blockchains have a list of approved members and skip most of the problems below, by bringing back an operator.
Finding the first peer when nobody hands you a list
Bitcoin: seven DNS names, a fixed list and a local address book
A new Bitcoin Core node starts with DNS. As of its current source code it knows seven seeds, such as seed.bitcoin.sprovoost.nl and dnsseed.emzy.de. It queries three of them at once, after a wait of 11 seconds when it knows fewer than 1,000 addresses, and each answer is simply a list of node addresses. If DNS gives nothing, the program falls back after about a minute on a list of fixed addresses compiled into the release.
So the start is not fully trustless, and the project says so in its rules. A seed operator must follow a written policy: results “must consist exclusively of fairly selected and functioning Bitcoin nodes”. A dishonest seed could still hand a newcomer a poisoned list, which is one reason a node asks several seeds run by different people. After the first run, seeds matter little. The node keeps its own address book, called addrman, and it learns new addresses from peers through addr messages, up to 1,000 in a message and processed at a limited rate of 0.1 address per second per peer.
The address book has two tables. The “new” table holds addresses heard from others: 1,024 buckets of 64 entries, or 65,536 slots. The “tried” table holds addresses the node has actually reached: 256 buckets of 64, or 16,384 slots. About every 2 minutes on average, a short-lived feeler connection tests an unverified address and moves it across if it answers. A listening node also announces its own address about once every 24 hours, so it keeps being rediscovered.
Ethereum: bootnodes, a distributed table and signed node records
Ethereum clients ship with a few hard-coded bootnodes, used only to introduce a newcomer. The ethereum.org networking page describes two layers since the Merge, each with its own network. Execution clients run discovery over UDP, currently Discv4, a Kademlia-like table, with work under way to move to Discv5, and they talk over devp2p (RLPx) on TCP. Consensus clients use Discv5 with libp2p. Discv5 is, in its own specification, “loosely inspired by the Kademlia DHT”, and it stores Ethereum Node Records: small signed cards with an identity, a sequence number that rises on each change, and key-value data such as the client’s network and the subnets it follows.
The difference with Bitcoin is one of method. Bitcoin’s address book is a pile of gossip, filtered by trial. Ethereum’s discovery is a structured search: a node asks for peers closer and closer to a target identifier, then filters on what the record says.
Solana: entrypoints and a published schedule
Solana needs discovery less than the others in one respect. An Agave validator is started with one or more entrypoint addresses and fills a gossip table from there, and the order of block producers is worked out in advance: nodes update their leader schedule at each epoch boundary, roughly every two days, according to an analysis by Helius. A machine that knows who produces the next blocks knows where to send things, and that shapes everything in the gossip section below.
| Network | First contact | Ongoing discovery | Transport |
|---|---|---|---|
| Bitcoin | 7 DNS seeds, then fixed addresses | addr gossip, local tables | TCP, port 8333; encrypted v2 (BIP 324); Tor, I2P, CJDNS |
| Ethereum, execution layer | Hard-coded bootnodes | Discv4 over UDP, moving to Discv5 | devp2p (RLPx) over TCP |
| Ethereum, consensus layer | Bootnodes | Discv5 over UDP | libp2p: QUIC first, TCP as well |
| Solana | Entrypoint addresses given at start | Gossip table, plus a published leader schedule | QUIC to leaders; shreds through Turbine |
How many neighbours a node keeps, and who they are
Peer numbers look like housekeeping. They are a security decision. Outbound connections, the ones your node chose, are the valuable ones, because an attacker cannot simply dial in and take them. Bitcoin Core keeps them few and steady: 8 full-relay and 2 block-relay-only, plus the occasional feeler, and an extra block-relay-only peer tried about every 5 minutes on average. The outbound slots are filled from different network groups, so one small IP range cannot take them all.
The headline number changed days ago. The total default limit was 125 for years, and many older guides still say so. Bitcoin Core 32.1, released on 28 October 2026, states in its release notes that the default “has increased from 125 to 200”. The 32.0 tag was never fully released, so 32.1 is the first public version with the change. The extra room is inbound capacity for block-relay-only peers, transaction-relaying peers may take at most 50% of inbound slots, and automatic outbound connections stay as they were. In the Bitnodes snapshot of 2 November 2026, 09:01 UTC, by our own count of user agents, 3,071 of the 18,526 reachable nodes reported version 32 and the rest older software or other clients, so both limits are live on the network.
| Client (as of 2 November 2026) | Default | Note |
|---|---|---|
| Bitcoin Core 32.1 | 200 connections; 8 full-relay and 2 block-relay-only outbound | 125 until version 31; values above 2,000 are clamped |
| Geth 1.17.10 | MaxPeers 50 | Dial ratio of 3: about a third of peers are outbound |
| Lighthouse 8.3.2 (consensus client) | Target of 200 peers | A client default, not a protocol rule |
These are defaults in software. No protocol forces them, and an operator can change them.
Gossip: how a block crosses the network
Bitcoin: announce, ask, deliver
The base pattern takes three messages. A node that has something new sends inv, an inventory of hashes. A peer that lacks one answers getdata. The first node then sends the data. Announcing a hash before sending the bytes stops the network from carrying the same transaction many times over each link. The price is a round trip per hop, and in 2013 Decker and Wattenhofer found that this round trip dominated the delay for transactions, 96% of which were under 1 kB at the time.
Transaction announcements are also held back on purpose. In the current code, a node batches them with random delays averaging 2 seconds towards outbound peers and 5 seconds towards inbound ones. The delay costs time and buys privacy: it blurs which peer heard first. Version 32.1 keeps the default relay limit of 14 transactions per second, with a 2.5 times boost for outbound peers, and adds a 12 MB cap per 10 minutes.
Blocks got a different treatment. BIP 152, compact blocks, relies on a fact: a peer has already seen most transactions in a new block, in its mempool (a later lesson covers the mempool). So the sender ships a sketch of short identifiers, and the receiver rebuilds the block and asks only for what is missing. The Bitcoin Core FAQ of June 2016 gave an average of 9 kB to rebuild a 1 MB block. In high-bandwidth mode, a node asks a few peers (three at most, in the current code) to push new blocks without waiting to be asked.
Erlay tries to do for transactions what compact blocks did for blocks, by replacing most individual announcements with a periodic comparison of two peers’ sets. A 2025 item listed on Bitcoin Optech’s topic page says it “may save 100 MB a day of node bandwidth, 20% of total bandwidth for some nodes”. It has not shipped. BIP 330 remains a draft. In version 32.1 the code exists but is off by default, behind a debug-only option. A discussion opened in February 2026 asks whether it is worth continuing, and it was still open at its last update on 20 August 2026.
Ethereum: hashes for transactions, gossipsub for blocks
Since the Merge, block propagation belongs to the consensus layer. The execution network mainly exchanges transactions, with an idea close to Bitcoin’s: NewPooledTransactionHashes announces hashes and peers fetch the bodies they lack.
The consensus layer uses gossipsub on libp2p, and the specification gives its numbers. Each node keeps a mesh of about 8 peers per topic (between 6 and 12), and it sends lighter metadata to 6 more, on a heartbeat of 0.7 seconds. Topics split traffic by kind: beacon_block for blocks, beacon_aggregate_and_proof for aggregated votes, 64 attestation subnets for individual votes, and, since the Fulu fork, 128 subnets for data columns. A node need not hear everything. That is how the layer copes with a validator set too large for everyone to hear everyone.
Solana: a tree instead of a crowd
Solana drops gossip for block data. Its leader cuts the block into shreds and sends them into Turbine, a tree rebuilt for each shred through a stake-weighted shuffle, so higher-staked validators tend to sit nearer the top. In the Agave source, each node forwards to at most 200 others, and a shred takes at most 4 hops. Erasure coding covers the losses: with 32 data and 32 coding shreds, the documentation’s worked example, which assumes 15% packet loss, puts block success at about 0.99.
Turbine is still the current design. Anza’s Alpenglow page, dated 29 October 2026, says the new consensus is live on mainnet-beta, with 10/21 as the milestone, and lists Rotor, which would replace the tree with a single relay hop, under what comes next. It gives no date for Rotor.
Transactions take another road. Solana has no public mempool in the Bitcoin sense: RPC nodes send a transaction over QUIC straight to the current and next leaders, known from the schedule. Agave’s send-transaction service forwards to 2 leaders by default and retries every 2 seconds. The name for this approach, from the founders’ blog posts of 2019, is Gulf Stream, though Helius found only a single trivial mention of it in the code: read it as a label for a behaviour.
Why latency is a security parameter
What has been measured
Measurements of propagation exist, but they do not share one definition. The table sets them side by side and should not be read as one series: the Bitcoin rows time when nodes receive a block, while the ethPandaOps row times the spread after the first sentry saw it.
| Study | Network | Median | Tail | Fork or orphan rate |
|---|---|---|---|---|
| Decker and Wattenhofer, 2013 | Bitcoin | 6.5 s (mean 12.6 s) | 5% of nodes still waiting after 40 s | 1.69% observed, 1.78% modelled |
| Fechner et al., published 2022 | Bitcoin | 0.454 s (mean about 4.1 s) | 5% of nodes later than 15.8 s | 0.014% to 0.127% across four chains |
| ethPandaOps, 25 April to 2 May 2026 | Ethereum | 104 ms (9 kB) to 348 ms (about 238 kB) | p99 of 427 ms to 1,248 ms | Not measured |
| Chainbound, November 2025 | Ethereum | Not given | Block validation p99 at or above the 4 s deadline, by blob count | 584 of 216,000 slots, 0.27% |
Bitcoin’s improvement is large. In 2013, the median node waited 6.5 seconds for a block. In the paper by Fechner, Chandrasekaran and Makkes, “The majority of peers in all four blockchains learn of a newly mined block within one second”. Their caveats: one observer in Amsterdam, IPv4 only, seeing about 27% of reachable Bitcoin nodes. Compact blocks arrived between the two studies, along with other changes to the software.
From delay to stale block
Delay matters because of what miners do while they wait. Two miners find valid blocks at nearly the same moment, each sends its own, and the network holds two views for a while. Nodes keep working on the first one received. When the next block lands on one side, the chain with more proof of work wins and nodes on the other side reorganise. The losing block is stale: valid, but no longer part of the chain, and the miner’s reward goes with it. Those are the reorgs you read about, and they are why a confirmation is a probability that grows (why old blocks become hard to change goes further).
Decker and Wattenhofer set out to test whether propagation delay is the primary cause of forks. Their model predicted 1.78% and they observed 1.69% over 10,000 blocks from height 180,000. Then they ran a modified client as a hub, connected to 3,048 nodes on average, with some relay changes on top. Between heights 200,000 and 210,000 the fork rate fell to 0.78%.
Ethereum shows the same cause under different rules. Its proof-of-stake attesters must see a block by a deadline of 4 seconds into the slot, so a late block can lose its votes. Chainbound counted 584 orphaned blocks in 216,000 slots in November 2025, and its post shows validation at the tail reaching that deadline. ethPandaOps, in a report of 6 May 2026 on 50,318 blocks, concluded: “The 4-second attestation deadline is not at risk for any size band currently on mainnet.” The two are not in conflict, since one looks at validation with blobs and the other at dispersion after the first sighting.
Attacks that target the network, not the chain
Consensus attacks get the headlines, and can a blockchain be hacked covers them. The attacks below go after something else: what a node gets to hear. None of them can make a full node accept an invalid block, because the node checks every rule by itself.
Sybil: one actor, many faces
John Douceur named it in a paper of January 2002: “if a single faulty entity can present multiple identities, it can control a substantial fraction of the system”. He also showed that without a central authority, such attacks stay possible short of unrealistic assumptions. Blockchains accept that result and put the cost where it counts: voting power takes hashrate or stake. The network layer has no such price. A peer identity costs an IP address, so counting nodes proves little, and a majority of nodes means nothing for consensus.
Eclipse: surrounding a single node
An eclipse attack aims all of one victim’s connections at the attacker. Heilman, Kendler, Zohar and Goldberg showed in 2015 that an adversary with enough IP addresses could “monopolize all connections to and from a victim bitcoin node”. Their figures, for the software of the time: a botnet of 4,600 bots could eclipse a victim with at least 85% probability whatever the network size, 32 distinct /24 blocks (8,192 addresses) could do the same, and 400 bots were enough against their own live nodes. The trick was to fill the address book with attacker addresses, wait for the node to restart, and take every slot.
What does the attacker gain? The victim can be starved of blocks, or shown a valid but stale view of the chain. A merchant accepting unconfirmed payments can be double-spent, since the merchant’s transaction never reaches anyone else (a later lesson covers double spending). If eclipsed miners are in the mix, the paper describes block races, split mining power, easier selfish mining and double spends even after N confirmations.
The authors told Bitcoin Core developers in February 2015, and three of their countermeasures shipped in bitcoind 0.10.1, among them four times more buckets. Later code added more: block-relay-only peers, which reveal less about the node’s topology because they relay no addresses or transactions; two anchor peers saved at shutdown and tried first at restart; feelers; and the optional -asmap file, which sorts peers by network operator instead of IP range. The numbers of 2015 no longer apply to current software.
BGP hijack and network partition
Internet routing rests on trust between network operators, through the Border Gateway Protocol. Apostolaki, Zohar and Vanbever measured what that meant for Bitcoin in a paper of 2017. On the project’s data of 2015 and 2016, 13 ISPs hosted 30% of the network, and 60% of all possible connections crossed 3 ISPs. They calculated that hijacking fewer than 100 BGP prefixes could isolate up to 47% of the mining power, which is a partition: two sides that keep mining apart, until the side with less work loses its blocks on reconnection. A subtler delay attack, run by an attacker sitting on the traffic’s path, could hold a block back from a victim for up to 20 minutes without breaking the connection.
The paper is careful about what was shown. The authors hijacked only their own nodes on the live network, where all traffic moved to the attacking route within 1.5 minutes. They tested a 50-50 split on a testbed of 1,050 clients, not on Bitcoin itself, and the two sides reconnected quickly. For the real internet they scanned BGP data from October 2015 to March 2016: traffic for at least 100 Bitcoin nodes a month was diverted, and 447 nodes (about 7.8% of the network) in November 2015. That is exposure, not proof of an attack on Bitcoin. A footnote warns that each hijack “may have been aimed at other services in the same IP range”.
A neighbouring case shows the same weakness around the chain. On 24 April 2018, eNET (AS10297) announced more-specific routes for Amazon’s Route 53 addresses for almost two hours, from about 11:05 UTC. The traffic reached a malicious DNS server in Chicago, and Cloudflare reported that users of MyEtherWallet were sent to a fake copy of the site, which showed a TLS certificate signed by an unknown authority. Victims had to click through that warning before their logins were stolen. That was DNS plus BGP against a web front end, and no peer-to-peer layer was touched.
| Attack | Source | Resource | Effect | Defences |
|---|---|---|---|---|
| Sybil | Douceur, 2002 | Many identities | Outsized share of a view | Costly votes (work, stake); peer diversity |
| Eclipse | Heilman et al., 2015 | 4,600 bots or 32 /24 blocks (2015 software) | Victim sees only the attacker | Bigger tables, anchors, feelers, block-relay-only peers, asmap |
| BGP partition or delay | Apostolaki et al., 2017 | Fewer than 100 prefixes hijacked | Split or delayed network | Diverse connections, encrypted traffic, relay proposals such as SABRE |
| DNS and BGP against an app | Internet Society, 2018 | One network announcing false routes | Users sent to a fake site | Route filtering; heeding certificate warnings |
What Tor, I2P and encryption change for privacy
A peer-to-peer network is not anonymous by default. A clear-net node shows its IP address to each peer, and a peer watching timing can guess which node first sent a transaction. Bitcoin’s answers come in layers.
Encrypted transport, BIP 324, has been on by default since Bitcoin Core 27.0 in April 2024. It hides content from a passive eavesdropper and forces an attacker to become active. Its encryption is unauthenticated by design, so it does not prove who is on the other end.
Tor and I2P hide the IP address itself. The Bitnodes snapshot of 2 November 2026 at 09:01 UTC lists 7,841 onion addresses and 4,624 I2P addresses, against 5,453 on IPv4 and 601 on IPv6. An address is not a machine: one operator can sit behind many of them. CJDNS had 7, and the 32.1 notes say the project is considering dropping it.
Dandelion, the proposal to pass a transaction along a private path before broadcasting it, never reached Bitcoin Core. BIP 156 has the status Closed. What shipped instead, in version 31.0, is an opt-in -privatebroadcast mode for sendrawtransaction: it sends each transaction over Tor or I2P, one connection per transaction, so that recipients do not learn the origin and two transactions cannot be linked. It is off by default, and version 32.1 fixed a possible leak of the originator’s address in it.
Reading the network as it stands today
That snapshot gave 18,526 reachable nodes in total, at block 974,233, and the figure needs its caveats. It counts machines that accept inbound connections. Nodes behind a home router or firewall are invisible, and one operator can run several addresses. Bitnodes itself says it is being rebuilt independently under a new operator, and its count is noisy: the eight snapshots up to 09:01 UTC ranged from 18,526 to 18,899. So 18,526 is neither the number of nodes nor the number of independent parties. Chainbound cited about 20,000 nodes on Ethereum mainnet for late 2025.
Hosting is the other reading. In the Fechner study, Amazon hosted 7.7% of observed Bitcoin nodes, Google 3.78%, Digital Ocean 3.3% and OVH 2.24%, and 5.17% sat in networks of state-owned operators. Those shares are old and cover a part of the network, and the study itself calls no single provider’s share significant for Bitcoin. Still, they sit on the same internet whose routing the BGP section described.
If you run a node, you can inspect your own corner of this. Two commands show the connections by type and network, and the transport each peer uses.
bitcoin-cli -netinfo 4
bitcoin-cli getpeerinfoLook for the outbound count and the connection_type and transport_protocol_type fields. The node lesson has the hardware and sync notes. Three things to watch from here: how many nodes move to the 200-connection default, whether the Erlay discussion ends with a decision, and when Anza dates Rotor. The 32.1 notes also warn that older I2P setups will lose support for legacy ElGamal on or before version 34.
