BSV P2P Network
A Technical Guide
How nodes discover each other, how blocks and transactions propagate, and what changes as the network evolves toward Teranode architecture.
I'm a BSV developer who has built several applications on the protocol and spent considerable time studying it from the outside in. I don't have visibility into any miner's infrastructure; their setups are private by design, and that's reflected in this guide. I've run SV Node software once as an experiment. I haven't run Teranode yet, though I intend to, and that hands-on perspective will sharpen some of what's written here. What follows is my best understanding drawn from the protocol documentation, source code, and what the network itself reveals from the outside.
How Nodes Find Each Other: DNS Seeds
When a BSV node starts up for the first time, it needs to find other nodes on the network. It does this by querying DNS seeds — special DNS servers that return IP addresses of known public nodes, rather than website addresses.
Unlike regular DNS lookups that resolve domain names to servers hosting a website, Bitcoin DNS seeds resolve to IP addresses of nodes that are currently accepting P2P connections. A newly-launched node queries these seeds, gets a list of IPs, connects to them on port 8333, and begins participating in the network.
| Official DNS Seed | Role | Status (March 2026) |
|---|---|---|
| seed.bitcoinsv.io | Primary BSV seed | Active — returns a small number of working IPs |
| seed.satoshisvision.network | Secondary seed | Degraded — returns IPs that refuse connections |
| seed.bitcoinseed.directory | Secondary seed | Partially active — connection issues reported |
In one relay-bridge snapshot taken in late March 2026, the number of public P2P nodes discoverable via DNS seeds temporarily dropped from 19 connected peers on March 22 to 3 on March 24. By the following day, the count had risen again. The remaining nodes in that snapshot were hosted on OVH cloud infrastructure across three continents (Germany, Singapore, and Canada), suggesting they may have been operated by a single entity providing geographic redundancy.
Whether this reflected a temporary fluctuation, possibly related to the upcoming Chronicle hard fork on April 7, or something else was unclear. In the same period, the DNS seeds showed signs of inconsistency: seed.satoshisvision.network returned IP addresses that refused connections, and seed.cascharia.com (a non-official seed still referenced by some software) returned nothing at all.
DNS seeds only index nodes that actively accept inbound connections from anyone on the internet. This is a much smaller set than the full network; miners and infrastructure operators typically run nodes with restricted access.
Public Nodes vs. Mining Infrastructure
Perhaps an important distinction in understanding BSV's network topology is that DNS seeds and miners are entirely separate concepts. DNS seeds return public relay nodes. Miners, the entities actually producing blocks, are not typically observed in DNS seed results.
Miners use the same port (8333) and the same protocol as other nodes, but in practice they are not typically publicly reachable. Because DNS seeds index nodes that accept inbound connections, mining infrastructure is generally not represented in seed results. Miners also typically bypass seed discovery entirely, using hardcoded peer configuration (addnode/connect) to connect directly to known trusted peers.
This means that even when only a few public relay nodes are discoverable via DNS seeds, blocks from all miners still propagate through; the public relay layer bridges private mining infrastructure to the rest of the world.
How Blocks and Transactions Propagate
BSV uses a gossip protocol for propagating both blocks and transactions. Rather than broadcasting to all nodes simultaneously, each node tells its connected peers about new data, and each peer does the same. Information spreads organically across the network through repeated announcement and retrieval.
Block Propagation (3 messages)
Transaction Propagation (3 messages)
The two-step announcement pattern (first inv, then getdata) is intentional: it lets nodes avoid downloading data they already have. If a node receives an inv for a transaction it already knows about, it simply doesn't respond.
The Bitcoin P2P Protocol
The core Bitcoin P2P protocol is remarkably stable. The fundamental message patterns used today, including inv, getdata, tx, and block, remain consistent with Satoshi's original implementation released in January 2009. Port 8333 was hardcoded in Bitcoin's very first release and has remained the default ever since.
| Message | Purpose | Still Used |
|---|---|---|
| version / verack | Handshake: nodes identify themselves and agree to communicate | Yes |
| inv | Announce available data (block or transaction) | Yes |
| getdata | Request specific data by hash | Yes |
| tx | Deliver a full transaction | Yes |
| block | Deliver a full block | Yes |
| getheaders / headers | Request and deliver block headers (used in SPV) | Yes |
| getaddr / addr | Request and share known peer addresses | Yes |
| ping / pong | Keepalive: confirm the connection is still live | Yes |
| checkorder / submitorder | Early e-commerce order features, never widely used | Removed |
DNS seeds were not part of Satoshi's original design; they were introduced around 2012. The original Bitcoin v0.1.0 used IRC (Internet Relay Chat) for peer discovery: nodes would join a channel, encode their IP address into their nickname, and read other nicknames to find peers. IRC served as a phonebook only; actual Bitcoin traffic always flowed over port 8333.
The P2P handshake begins with a version message containing the node's software version, current block height, and network services it supports. The peer responds with its own version, then both send verack to confirm the connection. All subsequent communication uses the message types above.
TCP and Port 8333 Explained
BSV's P2P network runs over TCP (Transmission Control Protocol), the same reliable transport layer used by web browsers, email, and SSH. Bitcoin chose TCP deliberately: blocks and transactions must arrive complete and in order, with no tolerance for missing data.
A port is a numeric identifier that distinguishes different services running on the same server, like apartment numbers in a building. Well-known port assignments include 80 (HTTP), 443 (HTTPS), 22 (SSH), and 8333 (Bitcoin P2P).
A node with port 8333 open accepts inbound connections from any IP address; this is what gets listed by DNS seeds. A node with port 8333 closed to the public can still connect outbound to other nodes, but nobody can initiate a connection inward. Mining infrastructure commonly operates in this mode, which is why it is not typically observed in seed databases despite actively participating in the network.
Teranode: The Evolving Architecture
The current BSV node software (commonly called "SV Node") is a monolithic application that handles all functions, including peer networking, validation, mempool management, and block assembly, in a single process connected via TCP on port 8333. Teranode is a fundamentally different architecture: a suite of specialized microservices that communicate internally via message queues rather than direct P2P connections.
| Dimension | SV Node (Current) | Teranode (Evolving) |
|---|---|---|
| Architecture | Monolithic application | Microservices |
| Transport | TCP, port 8333 | HTTP + gRPC |
| Block data access | getdata MSG_BLOCK via P2P |
HTTP via Asset Service |
| Transaction submission | P2P tx message |
ARC (HTTP API) |
| Peer discovery | DNS seeds + addr messages |
libp2p DHT + banlists |
| Block propagation | Direct block message |
HTTP via Asset Service endpoint |
Teranode's architecture includes microservices such as the Asset Server (block and transaction data), P2P Service (networking layer), Propagation Service, Validator Service, Block Assembly Service, and a Legacy P2P Bridge that maintains backward compatibility with SV Node.
Chronicle represents the final protocol restoration milestone for SV Node, completing the work begun by Genesis, before Teranode eventually supersedes it. Both node implementations will speak the same restored protocol, enabling the gradual, parallel transition that the BSV Association has planned rather than a hard cutover.
The practical implication for developers is that applications built today against SV Node's P2P protocol remain valid during the transition — the Legacy P2P Bridge in Teranode is designed precisely to preserve this. Long-term, however, the ecosystem is moving toward HTTP APIs, ARC for transaction submission, and a networking model that looks far more like a modern web service than a traditional peer-to-peer gossip network.
SV Node will continue to run alongside Teranode through 2026 and into the foreseeable future. The P2P protocol on port 8333 remains fully functional during this period. Developers should plan for a gradual migration toward Teranode's HTTP APIs rather than an immediate cutover.
Glossary
A DNS server that returns IP addresses of public Bitcoin nodes, used for initial peer discovery when a node first starts up.
Direct communication between nodes without a central server. Bitcoin's network is P2P — every node talks directly to its peers.
Transmission Control Protocol. A reliable, ordered network transport that guarantees delivery. Bitcoin uses TCP because blocks and transactions cannot be lost or corrupted in transit.
The default TCP port for Bitcoin P2P communication. Hardcoded by Satoshi in the original v0.1.0 release in January 2009.
A P2P message announcing that a node has a specific piece of data (transaction or block) available. The first step in the gossip protocol.
A P2P message requesting a specific piece of data by its hash. Sent in response to an inv message to retrieve the actual content.
Type codes used in inv and getdata messages to distinguish between block announcements (type 2) and transaction announcements (type 1).
A propagation method where each node shares new data with its direct peers, who share with their peers, spreading information organically across the network.
A list of approved IP addresses allowed to connect to a node. Miners use IP whitelists on port 8333 to allow only known peers while blocking public access.
The next-generation BSV node software built as a microservices architecture, replacing the monolithic SV Node with specialized services communicating internally via HTTP and gRPC.
A BSV network upgrade targeting block 943,816 (~April 7, 2026). The final protocol restoration milestone for SV Node, completing the work begun by Genesis, before Teranode eventually supersedes it.
A Teranode microservice for transaction submission and processing, accessed via HTTP API rather than the traditional P2P tx message.
Simplified Payment Verification. A lightweight method of validating transactions using block headers rather than downloading full blocks. Relies on the getheaders / headers message flow.
Bitcoin's original peer discovery method (pre-2012). Nodes joined an IRC channel and encoded their IP address in their nickname. Replaced by DNS seeds.
If you have direct experience with any of this infrastructure and think something here is incomplete or incorrect, I'd genuinely like to know. Find me on X at @hbnostic.