Why Bitcoin's Original Design Needed IPv6 — And How Hurricane Electric Powers the Mandala

Bitcoin v0.1 (Satoshi’s original protocol) used 16-byte IPv6 addresses in the addr message from day one
BSV’s Mandala network needs densely-connected core routing where IPv6 eliminates NAT barriers
Hurricane Electric runs the world’s largest IPv6 backbone and provides the transit infrastructure that makes Mandala’s core viable

Here’s the full map.

Part 1: Bitcoin v0.1 — IPv6 Was in the Original Protocol

Open the Bitcoin v0.1 source code from January 2009. In net.h, the CAddress class:

class CAddress
{
    ...
    char pchReserved[12];  // 12-byte prefix for IPv4-mapped IPv6
    unsigned int ip;       // 4 bytes of actual IP
    unsigned short port;   // port number
    ...
    
    bool IsIPv4() const
    {
        return (memcmp(pchReserved, pchIPv4, sizeof(pchIPv4)) == 0);
    }
};

The addr message format in the P2P protocol uses a 16-byte IPv6 address field:

Field Size  Description     Data type    Comments
4           time            uint32       timestamp
8           services        uint64       service flags
16          IPv6/4          char[16]     IPv6 address (network byte order)
2           port            uint16       port number

IPv4 addresses are stored as IPv4-mapped IPv6 addresses (::ffff:x.x.x.x). The wire format always used 16 bytes.

From the BSV Wiki:

The original client only supported IPv4 and only read the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte IPv4-mapped IPv6 address (12 bytes 00 00 00 00 00 00 00 00 00 00 FF FF, followed by the 4 bytes of the IPv4 address).

This means Satoshi designed the protocol for IPv6 from the beginning. The wire format supports it. The address relay supports it. The node discovery supports it. The only missing piece in 2009 was that IPv6 wasn’t widely deployed, so clients only read IPv4. But the protocol was ready.

By 2012, Bitcoin Core (via Pieter Wuille’s pull request #1021) enabled IPv6 at compile time. Today, BSV’s protocol supports native IPv6 peer addresses in the addrv2 message (BIP155), with network ID 0x02 for IPv6.

What IPv6 Enables at the Protocol Level

Part 2: Why IPv6 Matters for the Mandala Network

Recall the Mandala architecturdirection: down

App1: “App / Wallet” { shape: oval

Overlay1: “Overlay Service” { shape: rectangle

The core layer requires every Teranode to connect to almost every other Teranode. This is a nearly-complete graph where N nodes maintain O(N²) connections.

IPv4 makes this hard:

NAT exhaustion: Residential and many data centre IPs are behind NAT. You cannot establishe direct P2P connections without UPnP, STUN, or relay servers. Every NAT traversal adds latency and failure modes.
Port scarcity: Each node needs a public IP. IPv4 addresses cost $40-60 each on the secondary market. A Teranode farm with 1000 nodes needs 1000 public IPv4 addresses.
Carrier-grade NAT (CGNAT): Many ISPs (including Singtel) use CGNAT, where a single public IPv4 is shared across hundreds of customers. No incoming P2P connections possible.

IPv6 solves all of this:

Every node gets a globally routable /64 subnet: No NAT, no port forwarding, no STUN. Direct P2P by default.
No address scarcity: 2¹²⁸ addresses means every Teranode, every overlay service, every wallet can have a globally unique address.
End-to-end connectivity: The Mandala core’s dense mesh works because every Teranode can directly connect to every other Teranode without intermediaries.
Multicast support: An IETF presentation (Jake Jones, 2024) proposed using IPv6 multicast for block propagation — a single packet reaches all nodes in the core simultaneously, rather than relaying sequentially.

Without IPv6


Teranode A (NAT) → STUN server → Teranode B (NAT)
  ↕                                           ↕
  Relay proxy (cost, latency, failure point)

The Mandala core’s 1.3-hop ideal degrades because nodes behind NAT must route through relays, adding hops.

With IPv6


Teranode A (2001:db8::a) ←→ Teranode B (2001:db8::b)
  ↕                           ↕
Teranode C (2001:db8::c) ←→ Teranode D (2001:db8::d)

Direct connections. No relays. True dense mesh. The 1.3-hop property is preserved.

Part 3: Hurricane Electric — The IPv6 Backbone That Makes It Real

This is where the infrastructure economics connect.

Hurricane Electric (AS6939) is the world’s largest IPv6 backbone by connected networks. From the earlier post:

Metric	Value
Connected networks	10,500+
BGP sessions	34,000+
IXP connections	320+
IPv6 ranking	#1 by connected networks
Public peering capacity	52+ Tbps

When BSV’s Teranodes need IPv6 transit, HE is the natural provider because:

HE requires IPv6 peering alongside IPv4 — any network that peers with HE must support both protocols. This means every network in HE’s 10,500+ peer list is IPv6-capable.
HE’s open peering policy means a Teranode operator can peer with HE at any of 320+ IXPs worldwide without negotiation. Direct connectivity to 10,500+ networks.
HE offers native dual-stack on every transit port — IPv4 and IPv6 on the same connection at no extra cost. A Teranode farm in Fremont, Singapore, London, or Tokyo gets both addresses.
HE’s backbone is self-healing rings — 5+ redundant 100G paths across North America, separate 100G paths between US and Europe, 100G rings in Europe and Asia. This matches the Mandala’s resilience requirement.

The Connection

What This Means for a BSV Teranode Operator

If you’re running a Teranode as part of the Mandala core:

Order a cross-connect to HE at your data centre (Equinix SG, Global Switch, etc.)
Get a /48 IPv6 prefix from HE (or bring your own)
Assign every Teranode a unique /64 — globally routable, no NAT
Peer with other Teranodes directly via IPv6 — no relays, no STUN
Connect to the Mandala core with direct P2P links

The result: every Teranode reaches every other Teranode in ~1 hop. The core forms a true nearly-complete graph. Block propagation latency drops to the physical limit of the longest fibre path.

The Full Map

The chain:

Satoshi designed the Bitcoin protocol with IPv6 addressing from the start. The addr message uses a 16-byte IPv6 field. IPv4 is stored as IPv4-mapped IPv6 (::ffff:x.x.x.x). 2.

BSV maintains this original protocol and extends it with the Mandala upgrade. The Teranode core needs a dense mesh where every node reaches every other node in ~1.3 hops. 3.

That dense mesh requires IPv6.

because IPv4 NAT prevents direct P2P connectivity at scale. IPv6 gives every Teranode a globally routable address. 4.

Hurricane Electric provides the world’s largest IPv6 backbone. Their open peering policy, native dual-stack transit, and presence at 320+ IXPs makes them the natural transit provider for a global Teranode network. 5.

The result: a Bitcoin network that operates as Satoshi designed — IPv6-native P2P, no NAT barriers, direct connections between every node in the core, and block propagation at the speed of light.

Expanded Context

Summary

Layer	What	Why IPv6 Matters
Protocol	Bitcoin v0.1 `addr` message	16-byte IPv6 field from day one — Satoshi designed for it
Network	BSV Mandala core (Teranodes)	Dense mesh requires direct P2P — IPv6 eliminates NAT
Transit	Hurricane Electric (AS6939)	World’s largest IPv6 backbone — 10,500+ IPv6-capable peers
Result	~1.3 hop core + global connectivity	True P2P mesh at scale, block propagation at physical limits

The original Bitcoin protocol was designed for a world where every node has a globally routable address and can connect directly to any other node. That world is IPv6. Hurricane Electric is the infrastructure provider that makes that world accessible to the Mandala network today. —

Sources: Bitcoin v0.1 source code (net.h), BSV Wiki (Peer-To-Peer Protocol, CAddress), BSV Blockchain docs (Mandala Upgrade), Hurricane Electric network page and peering policy, BIP155 (addrv2), IETF 121 presentation on IPv6 multicast in BSV (Jake Jones), Pieter Wuille’s IPv6 PR #1021 (2012).