The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 4
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification 2.
"P2P network" means the Zcash peer-to-peer network.
+uint8
, uint16
, and uint32
denote unsigned integer data types of the corresponding length (8, 16, or 32 bits respectively).
This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation Onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current addr
message.
This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current addr
message.
Tor v3 hidden services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old hidden services, among which better encryption and privacy 9. These services have 256-bit addresses and thus do not fit in the existing addr
message, which encapsulates onion addresses in OnionCat IPv6 addresses.
Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy 9. These services have 256-bit addresses and thus do not fit in the existing addr
message (unchanged from Bitcoin 7), which encapsulates onion addresses in OnionCat IPv6 addresses.
Other transport-layer protocols such as I2P have always used longer addresses. This change would make it possible to gossip such addresses over the P2P network, so that other peers can connect to them.
The addrv2
message is defined as a message where pchCommand == "addrv2"
. It is serialized in the standard encoding for P2P messages. Its format is similar to the current addr
message format described in 7, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to 8.
The addrv2
message is defined as a message where the command
field is (NUL-padded) "addrv2"
. It is serialized in the standard encoding for P2P messages. Its format is similar to the current addr
message format described in 7, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to 8.
This means that the message contains a serialized vector of the following structure:
@@ -82,7 +83,7 @@ Pull-Request: <https://githu
One message can contain up to 1,000 addresses. Clients MUST reject messages with more addresses.
-Field addr
has a variable length, with a maximum of 512 bytes (4096 bits). Clients SHOULD reject messages with longer addresses, irrespective of the network ID.
Field addr
has a variable length, with a maximum of 512 bytes (4096 bits). Clients MUST reject messages with a longer addr
field, irrespective of the network ID.
The list of reserved network IDs is as follows:
-@@ -109,7 +110,7 @@ Pull-Request: <https://githu
0x04
TORV3
32 -Tor v3 hidden service address +Tor v3 onion service address @@ -126,57 +127,56 @@ Pull-Request: <https://githu 0x05
Network ID 0x03
is intentionally not assigned. In BIP 155 3 it was assigned to Tor v2 hidden service addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
Network ID 0x03
is intentionally not assigned. In BIP 155 3 it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
Clients SHOULD gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.
Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.
-Further network ID numbers MUST be reserved in a new ZIP.
Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.
The IPV4
and IPV6
network IDs use addresses encoded in the usual way for binary IPv4 and IPv6 addresses in network byte order (big endian).
According to the spec 9, version 3 .onion
addresses are encoded as follows:
onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion" -CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]+
According to the spec 9, version 3 .onion
addresses are encoded as follows:
onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion" +CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes
where:
PUBKEY
is the 32 bytes Ed25519 master pubkey of the hidden service;VERSION
is a one byte version field (default value 0x03
);PUBKEY
is the 32-byte Ed25519 master pubkey of the onion service;VERSION
is a one-byte version field (default value 0x03
);".onion"
and ".onion checksum"
are constant strings;CHECKSUM
is truncated to two bytes before inserting it in onion_address
;H()
is the SHA3-256 cryptographic hash function.H()
is the SHA3-256 cryptographic hash function. 10Tor v3 addresses MUST be sent with the TORV3
network ID, with the 32-byte PUBKEY
part in the address field. As VERSION
will always be 'x03' in the case of v3 addresses, this is enough to reconstruct the onion address.
Tor v3 addresses MUST be sent with the TORV3
network ID, with the 32-byte PUBKEY
part in the addr
field. As VERSION
will always be 0x03 in the case of v3 addresses, this is enough to reconstruct the onion address.
Like Tor, I2P naming uses a base32-encoded address format 10.
-I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by .b32.i2p
.
Like Tor, I2P naming uses a base32-encoded address format 11.
+I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by .b32.i2p
. The base32 encoding does not include "="
padding characters.
I2P addresses MUST be sent with the I2P
network ID, with the decoded SHA-256 hash as address field.
Cjdns addresses are simply IPv6 addresses in the fc00::/8
range 11. They MUST be sent with the CJDNS
network ID.
Cjdns addresses are simply IPv6 addresses in the fc00::/8
range 12. They MUST be sent with the CJDNS
network ID. They are encoded in network byte order (big endian) as for the IPV6
network ID.
Support for this specification is signalled by peer protocol version 170015 (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet 6.
+Support for this specification is signalled by peer protocol version 170015 (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet 6.
Nodes that have not negotiated peer protocol version 170015 or higher on a given connection, MUST NOT send addrv2
messages on that connection.
A node that has negotiated peer protocol version 170015 or higher on a given connection, MAY still send addr
messages on the connection, and MUST handle received addr
messages as it would have done prior to this ZIP.
This ZIP is closely based on BIP 155 3, with the following changes:
+This ZIP is closely based on BIP 155 3, with the following changes:
addrv2
message is signalled by advertising a peer-to-peer protocol version of 170015 or higher, not by sending a sendaddrv2
message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example the MSG_WTX
inv type defined in ZIP 239 5, have taken the same approach to signalling.addrv2
message is signalled by advertising a peer protocol version of 170015 or higher, not by sending a sendaddrv2
message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example the MSG_WTX
inv type defined in ZIP 239 5, have taken the same approach to signalling.addrv2
messages with more than 1,000 addresses. Making this a consistent requirement promotes interoperability.TBD.
This ZIP is closely based on BIP 155 3, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.
+This ZIP is closely based on BIP 155 3, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.
Acknowledgements for BIP 155:
services
field to CompactSize
, to make the message more compact in the likely case instead of always using 8 bytes.10 | +NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions | +
---|
11 | I2P: Naming and address book |
---|
11 | +12 | Cjdns whitepaper: Pulling It All Together |
---|