search

zcash / zips

Zcash Improvement Proposals
https://zips.z.cash
MIT License
268 stars 152 forks source link

[ZIP 155] addrv2 message #542

Open daira opened 2 years ago

daira commented 2 years ago

This is necessary to support Tor v3 onion addresses. Tor v2 onion addresses are being deprecated according to this timeline.

Copied from the forum:

It looks as though BIP 155 is straightforwardly applicable to Zcash, except that the sendaddrv2 message does not correspond to how we normally signal compatibility with peer protocol changes. We normally use the peer protocol version.

I consider Bitcoin’s approach to peer protocol changes to be problematic for long-term protocol maintenance, since it leads to an exponential increase in the space of supported feature combinations. In Bitcoin’s approach, peer protocol features are independently supported or not by a node (signalled either by a feature flag or by whether it has sent a particular message), and nothing can be assumed about support for a later feature implying support for earlier ones. In Zcash’s approach, a given peer protocol version implies support for all features added up to that version — so the space of feature combinations only grows at most linearly. In fact it is effectively constant, as a side effect of older nodes dropping off the network if they do not upgrade to support a Network Upgrade. (Peer protocol version numbers are bumped either for Network Upgrades, or for peer protocol changes outside a Network Upgrade.)

[...]

I'm somewhat inclined to say that support for addrv2 should be signalled by Zcash peer protocol version 170015 (the same version that signals support for NU5 on mainnet). zcashd v5.0.0, that would set the mainnet NU5 activation height and advertise peer protocol version 170015, is currently scheduled to be released in early October.

Another option is to have addrv2 signalled by 170015 but NU5 by 170016 (updating ZIP 252). However, at least as far as zcashd is concerned, there is currently no plan to have an intermediate release between v4.5.0 that supports testnet NU5 activation, and v5.0.0 that supports mainnet NU5 activation (see the planned schedule). Therefore adding an intermediate protocol version seems to be unnecessary complexity.

zancas commented 2 years ago

I would like to make sure I understand this:

"In Zcash’s approach, a given peer protocol version implies support for all features added up to that version — so the space of feature combinations only grows at most linearly. "

Each pair of nodes negotiates a network versioned protocol.

If the peers' versions aren't equal, the lower number is the protocol used (selected during peer protocol negotiation).

Each protocol version contains an increasing set of features. That is, each version is a superset (non-strict) of the preceding version.

Since the lower version is used all features of the lower version are available which are guaranteed to be a subset (non-strict) of the higher versions feature set. Since the feature set is fixed for a given pair there's no need to consider different possible sets of features for a P2P connection, there's 1 well-defined set. The set of the lower protocol-version.

Since ZIP155 addvr2 is a new P2P network feature, it implies a new protocol version.

Any node running a lower version of the protocol will not support that feature, and since the lower-version of the protocol is used for a specific connection, the higher protocol-version node in the pair will used the subset of features implied by the lower-version number (for the P2P connection, i.e. node-pair under consideration).

In other words, by using the protocol-versioning approach, the network guarantees that nodes do not attempt to use (new) unavailable features with (older) less featureful peers. addrv2 is precisely such a feature.

This implies a stateful relationship between nodes, i.e. nodes must remember each other, but that's true in bitcoin anyway since nodes...