zecfoundation
/
zips
mirror of https://github.com/ZcashFoundation/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 155: change peer protocol version for `addrv2` support to ${PLACEHOLDER}. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2022-03-25 16:49:30 +00:00
parent f6e044429d
commit a223dfd931
2 changed files with 13 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
zip-0155.html
View File

@ -157,15 +157,16 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes</pre>
</section>
</section>
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Support for this specification is signalled by peer protocol version 170017 (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="id13" class="footnote_reference" href="#zip-0252">6</a>.</p>
<p>Nodes that have not negotiated peer protocol version 170017 or higher on a given connection, MUST NOT send <code>addrv2</code> messages on that connection.</p>
<p>A node that has negotiated peer protocol version 170017 or higher on a given connection, MAY still send <code>addr</code> messages on the connection, and MUST handle received <code>addr</code> messages as it would have done prior to this ZIP.</p>
<p>TODO: change ${PLACEHOLDER} to a specific peer protocol version.</p>
<p>Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet <a id="id13" class="footnote_reference" href="#zip-0252">6</a>.</p>
<p>Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MUST NOT send <code>addrv2</code> messages on that connection.</p>
<p>A node that has negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MAY still send <code>addr</code> messages on the connection, and MUST handle received <code>addr</code> messages as it would have done prior to this ZIP.</p>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is closely based on BIP 155 <a id="id14" class="footnote_reference" href="#bip-0155">3</a>, with the following changes:</p>
<ul>
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of 170017 or higher, not by sending a <code>sendaddrv2</code> 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 <code>MSG_WTX</code> inv type defined in ZIP 239 <a id="id15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
<li>Deployment: support for the <code>addrv2</code> message is signalled by advertising a peer protocol version of ${PLACEHOLDER} or higher, not by sending a <code>sendaddrv2</code> 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 <code>MSG_WTX</code> inv type defined in ZIP 239 <a id="id15" class="footnote_reference" href="#zip-0239">5</a>, have taken the same approach to signalling.</li>
<li>No Network ID for Tor v2 onion addresses: the Tor network is expected to have removed support for these addresses in the timeframe for deployment of this ZIP.</li>
<li>Clients MUST, rather than SHOULD, reject <code>addrv2</code> messages with more than 1,000 addresses. Making this a consistent requirement promotes interoperability.</li>
<li>Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks.</li>

14
zip-0155.rst
View File

@ -170,14 +170,16 @@ They are encoded in network byte order (big endian) as for the ``IPV6`` network
Deployment
----------
Support for this specification is signalled by peer protocol version 170017 (on
both Testnet and Mainnet). Note that this is the same peer protocol version that
TODO: change ${PLACEHOLDER} to a specific peer protocol version.
Support for this specification is signalled by peer protocol version ${PLACEHOLDER}
(on both Testnet and Mainnet). Note that this is the same peer protocol version that
signals support for NU5 on Mainnet [#zip-0252]_.
Nodes that have not negotiated peer protocol version 170017 or higher on a given
connection, MUST NOT send ``addrv2`` messages on that connection.
Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a
given connection, MUST NOT send ``addrv2`` messages on that connection.
A node that has negotiated peer protocol version 170017 or higher on a given
A node that has negotiated peer protocol version ${PLACEHOLDER} 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.
@ -188,7 +190,7 @@ Rationale
This ZIP is closely based on BIP 155 [#bip-0155]_, with the following changes:
* Deployment: support for the ``addrv2`` message is signalled by advertising a
peer protocol version of 170017 or higher, not by sending a ``sendaddrv2``
peer protocol version of ${PLACEHOLDER} 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