Addrv2

The older addr message carries a fixed 16 byte address field, which cannot hold a 32 byte Tor v3 onion address. BIP-155 replaces that field with a one byte network id plus an address of up to 512 bytes, capped at 1,000 entries per message. Run a node over Tor to keep your holdings off your home IP address, and addrv2 is how other nodes learn it exists.

How it works

Addrv2 keeps the shape of the message it succeeds and rewrites one field.

Each entry carries five things: a Unix timestamp for when that node was last seen connected, a service bit field moved to CompactSize encoding so it no longer always costs eight bytes, a one byte network id, the address itself, and a 16 bit port that must be zero where the network has none. BIP-155 reserves seven ids: 0x01 IPv4 at 4 bytes, 0x02 IPv6 at 16, 0x03 Tor v2 at 10, 0x04 Tor v3 at 32, 0x05 I2P at 32, 0x06 Cjdns at 16 and 0x07 Yggdrasil at 16. A message carrying more than 1,000 entries, an address longer than 512 bytes, or an address whose length disagrees with its id should all be rejected.

Two of those ids need a footnote. Tor v2 stopped working: version 2.0.0 of the BIP, dated 2025-10-01, records that clients must no longer gossip or relay id 0x03 and must ignore it on receive, and Bitcoin Core keeps the number in its enum while documenting TORV2 as no longer supported. Core does not implement the seventh id at all, since that enum, BIP155Network in src/netaddress.h, runs from IPV4 = 1 to CJDNS = 6 and stops there, with MAX_ADDRV2_SIZE set to the same 512 bytes the specification names.

Support is negotiated rather than assumed. A node announces it by sending sendaddrv2, and the timing is strict: only after the peer's version message and before verack, which Core enforces by disconnecting a peer that sends one late. Never send it and the peer keeps using the legacy format, silently dropping every address type the old field cannot express. Version 2.1.0, dated 2026-08-03, closed a related gap by ruling that IPv4 addresses wrapped in IPv6, the ::ffff:0:0/96 range, must not travel under the IPv6 id, because one machine arriving under two ids gets counted as two separate peers.

Where you see it

Addrv2 surfaces in Bitcoin Core as a network label rather than as anything you read directly.

The getpeerinfo call tags every connection with a network name, and getnodeaddresses takes one as an argument: the help text in src/rpc/net.cpp uses getnodeaddresses 4 "i2p" and -named getnodeaddresses network=onion count=12 as examples. The getaddrmaninfo call goes further, breaking the stored address pool down per network with new, tried and total counts before appending an all_networks total. The rows beyond ipv4 and ipv6 hold addresses no addr message could have encoded, however your node first heard of them.

The onion case shows how little actually travels. A Tor v3 address is 56 base32 characters before the .onion suffix, encoding a 32 byte ed25519 public key, a two byte SHA3-256 checksum and a one byte version. Only the public key goes on the wire, and the receiving node rebuilds the rest, since the version is always 3 and the checksum is a function of what it already holds.

For a holder this is plumbing with one visible consequence. Wallets that route everything over Tor by default, Wasabi among them, and wallets that reach your own node over Tor, such as Blockstream Green, all depend on onion peers being findable in the first place.

Addrv2 vs a bitcoin address

A bitcoin address and an addrv2 address share three letters and nothing else. An addrv2 entry is a location on a network, an answer to where a machine sits, and no amount of it can receive coins. Paste an onion address into a wallet's send field and it will be rejected as malformed, which is the correct outcome.