mirror of https://github.com/zcash/zips.git
ZIP 239: resolve open issue.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
e81037731b
commit
72d37b803c
|
|
@ -42,17 +42,17 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/516">https://githu
|
|||
<p>An <code>inv</code> or <code>getdata</code> message MUST NOT use the <code>MSG_WTX</code> inv type for v4 or earlier transactions, or on peer connections that have not negotiated at least the peer protocol version specified in <a href="#deployment">Deployment</a>.</p>
|
||||
<p>Note that <code>MSG_WTX</code> might also be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified for now.</p>
|
||||
<p><code>MSG_TX</code> and <code>MSG_WTX</code> entries may be mixed in arbitrary order in an <code>inv</code> message or a <code>getdata</code> message. Since these entry types are of different lengths (36 bytes or 68 bytes respectively including the 4-byte type field), this implies that the size of the message is not determined by its initial <code>count</code> field, and has to be determined by parsing the whole message.</p>
|
||||
<p><strong>Open issue:</strong></p>
|
||||
<ul>
|
||||
<li>Should we redefine <code>inv</code> and <code>getdata</code> to segregate <code>MSG_TX</code> and <code>MSG_WTX</code>, making these messages simpler / more efficient to parse? This could be done by adding new <code>invw</code> and <code>getdataw</code> messages. See <a id="id13" class="footnote_reference" href="#p2p-inv">10</a> and <a id="id14" class="footnote_reference" href="#p2p-getdata">11</a> for how <code>inv</code> and <code>getdata</code> respectively are currently defined in Bitcoin.</li>
|
||||
</ul>
|
||||
<section id="deployment"><h3><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||
<p>This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5. In <a id="id15" class="footnote_reference" href="#zip-0252">5</a>, the minimum protocol version that signals support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol version that enables support for this specification is also defined to be 170014 (on both Testnet and Mainnet).</p>
|
||||
<p>As specified in <a id="id16" class="footnote_reference" href="#zip-0200">2</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
|
||||
<p>This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5. In <a id="id13" class="footnote_reference" href="#zip-0252">5</a>, the minimum protocol version that signals support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol version that enables support for this specification is also defined to be 170014 (on both Testnet and Mainnet).</p>
|
||||
<p>As specified in <a id="id14" class="footnote_reference" href="#zip-0200">2</a>, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the <code>MSG_WTX</code> inv type until it has received the block preceding the NU5 network upgrade.</p>
|
||||
<p>Nevertheless, it is possible for a node to receive an <code>inv</code> or <code>getdata</code> message with a <code>MSG_WTX</code> inv type, on a peer connection that has negotiated protocol version 170014 or later, before NU5 has activated. The node MUST handle this case in the same way that it would after NU5 activation when it has no v5 transactions to relay. Receiving a <code>MSG_WTX</code> inv type on a peer connection that has negotiated a protocol version before 170014, on the other hand, SHOULD be treated as a protocol error.</p>
|
||||
<p>As the <code>MSG_WTX</code> inv type is only enabled between peers that both support it, older clients remain fully compatible and interoperable before NU5 activates, or on a chain in which it does not activate.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>A previous draft of this ZIP left as an open question whether to redefine <code>inv</code> and <code>getdata</code> to segregate <code>MSG_TX</code> and <code>MSG_WTX</code>. This could potentially have made these messages simpler or more efficient to parse, by avoiding variable-length entries in the message data. (See <a id="id15" class="footnote_reference" href="#p2p-inv">10</a> and <a id="id16" class="footnote_reference" href="#p2p-getdata">11</a> for how <code>inv</code> and <code>getdata</code> respectively are currently defined in Bitcoin.)</p>
|
||||
<p>This option was rejected because the current specification is simple enough.</p>
|
||||
</section>
|
||||
<section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||
<p>This ZIP is partly based on BIP 339, written by Suhas Daftuar. <a id="id17" class="footnote_reference" href="#bip-0339">9</a></p>
|
||||
</section>
|
||||
|
|
|
|||
21
zip-0239.rst
21
zip-0239.rst
|
|
@ -114,15 +114,6 @@ message or a ``getdata`` message. Since these entry types are of different lengt
|
|||
that the size of the message is not determined by its initial ``count`` field, and
|
||||
has to be determined by parsing the whole message.
|
||||
|
||||
**Open issue:**
|
||||
|
||||
* Should we redefine ``inv`` and ``getdata`` to segregate ``MSG_TX``
|
||||
and ``MSG_WTX``, making these messages simpler / more efficient to parse?
|
||||
This could be done by adding new ``invw`` and ``getdataw`` messages.
|
||||
See [#p2p-inv]_ and [#p2p-getdata]_ for how ``inv`` and ``getdata``
|
||||
respectively are currently defined in Bitcoin.
|
||||
|
||||
|
||||
Deployment
|
||||
----------
|
||||
|
||||
|
|
@ -153,6 +144,18 @@ older clients remain fully compatible and interoperable before NU5 activates, or
|
|||
a chain in which it does not activate.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
A previous draft of this ZIP left as an open question whether to redefine ``inv`` and
|
||||
``getdata`` to segregate ``MSG_TX`` and ``MSG_WTX``. This could potentially have made
|
||||
these messages simpler or more efficient to parse, by avoiding variable-length entries
|
||||
in the message data. (See [#p2p-inv]_ and [#p2p-getdata]_ for how ``inv`` and ``getdata``
|
||||
respectively are currently defined in Bitcoin.)
|
||||
|
||||
This option was rejected because the current specification is simple enough.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
================
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue