mirror of https://github.com/zcash/zips.git
Leave it unspecified whether MSG_TXV5 is used for v6 and later transactions.
The previous wording could have been misinterpreted to require not using MSG_TXV5 for these, and was partly redundant. Also mention in Motivation that the format of serialized v5 transactions is not consensus-critical. Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
864e1eaa8d
commit
1b5786ea38
|
@ -28,16 +28,16 @@ Pull-Request: <<a href="https://github.com/zcash/zips/pull/516">https://githu
|
||||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>Historically, as in Bitcoin, the <code>inv</code> and <code>getdata</code> messages sent on the Zcash peer-to-peer network to announce or request transactions have referred to those transactions by txid.</p>
|
<p>Historically, as in Bitcoin, the <code>inv</code> and <code>getdata</code> messages sent on the Zcash peer-to-peer network to announce or request transactions have referred to those transactions by txid.</p>
|
||||||
<p>Prior to the introduction of v5 transactions <a id="id5" class="footnote_reference" href="#zip-0225">3</a> in the NU5 network upgrade <a id="id6" class="footnote_reference" href="#zip-0252">5</a>, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.</p>
|
<p>Prior to the introduction of v5 transactions <a id="id5" class="footnote_reference" href="#zip-0225">3</a> in the NU5 network upgrade <a id="id6" class="footnote_reference" href="#zip-0252">5</a>, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.</p>
|
||||||
<p>For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data <a id="id7" class="footnote_reference" href="#zip-0244">4</a>. Witness data is committed to by a separate "authorizing digest".</p>
|
<p>For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data <a id="id7" class="footnote_reference" href="#zip-0244">4</a>. Witness data is committed to by a separate "authorizing digest". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.</p>
|
||||||
<p>Not committing to the witness data in v5 transaction announcements would create inefficiencies: because a v5 transaction's witness can be malleated without altering the txid, a node in receipt of a v5 transaction that the node does not accept would generally still have to download that same transaction when announced by other peers. This is because the alternative — of not downloading a v5 transaction with a given txid after rejecting a previous transaction with that txid — would allow a third party to interfere with transaction relay by malleating a transaction's witness and announcing the resulting invalid transaction to nodes, preventing relay of the valid version of the transaction as well.</p>
|
<p>Not committing to the witness data in v5 transaction announcements would create inefficiencies: because a v5 transaction's witness can be malleated without altering the txid, a node in receipt of a v5 transaction that the node does not accept would generally still have to download that same transaction when announced by other peers. This is because the alternative — of not downloading a v5 transaction with a given txid after rejecting a previous transaction with that txid — would allow a third party to interfere with transaction relay by malleating a transaction's witness and announcing the resulting invalid transaction to nodes, preventing relay of the valid version of the transaction as well.</p>
|
||||||
<p>This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade <a id="id8" class="footnote_reference" href="#bip-0141">8</a>, until the adoption of BIP 339 <a id="id9" class="footnote_reference" href="#bip-0339">9</a>. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is the pair (txid, auth_digest).</p>
|
<p>This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade <a id="id8" class="footnote_reference" href="#bip-0141">8</a>, until the adoption of BIP 339 <a id="id9" class="footnote_reference" href="#bip-0339">9</a>. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is the pair (txid, auth_digest).</p>
|
||||||
<p>This ZIP is modelled after BIP 339: it adds a <code>MSG_TXV5</code> inv type to the peer-to-peer protocol, analogous to BIP 339's <code>MSG_WTX</code> inv type, that announces transactions by their (txid, auth_digest) pair. It does not introduce any equivalent of BIP 339's <code>wtxidrelay</code> message, since that is not needed for compatibility given that Zcash full nodes are required to support <code>MSG_TXV5</code> based on the negotiated peer protocol version (see <a href="#deployment">Deployment</a>).</p>
|
<p>This ZIP is modelled after BIP 339: it adds a <code>MSG_TXV5</code> inv type to the peer-to-peer protocol, analogous to BIP 339's <code>MSG_WTX</code> inv type, that announces transactions by their (txid, auth_digest) pair. It does not introduce any equivalent of BIP 339's <code>wtxidrelay</code> message, since that is not needed for compatibility given that Zcash full nodes are required to support <code>MSG_TXV5</code> based on the negotiated peer protocol version (see <a href="#deployment">Deployment</a>).</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>A new inv type <code>MSG_TXV5</code> (0x00000005) is added, for use in both <code>inv</code> messages and <code>getdata</code> requests, indicating that the hash being referenced is the 64-byte value <code>txid</code> || <code>auth_digest</code>. This inv type MUST be used when announcing v5 transactions, and only for such transactions. The <code>txid</code> and <code>auth_digest</code> are as defined in <a id="id10" class="footnote_reference" href="#zip-0244">4</a>.</p>
|
<p>A new inv type <code>MSG_TXV5</code> (0x00000005) is added, for use in both <code>inv</code> messages and <code>getdata</code> requests, indicating that the hash being referenced is the 64-byte value <code>txid</code> || <code>auth_digest</code>. This inv type MUST be used when announcing v5 transactions. The <code>txid</code> and <code>auth_digest</code> are as defined in <a id="id10" class="footnote_reference" href="#zip-0244">4</a>.</p>
|
||||||
<p>In the case of <code>getdata</code> requests, the format of a v5 transaction obtained by a <code>MSG_TXV5</code> inv type is as given in the Zcash protocol specification. <a id="id11" class="footnote_reference" href="#protocol-txnencodingandconsensus">7</a></p>
|
<p>In the case of <code>getdata</code> requests, the format of a v5 transaction obtained by a <code>MSG_TXV5</code> inv type is as given in the Zcash protocol specification. <a id="id11" class="footnote_reference" href="#protocol-txnencodingandconsensus">7</a></p>
|
||||||
<p>An <code>inv</code> or <code>getdata</code> message MUST NOT use the <code>MSG_TXV5</code> inv type for v4 transactions, or on peer connections that have not negotiated at least the peer protocol version specified in <a href="#deployment">Deployment</a>.</p>
|
<p>An <code>inv</code> or <code>getdata</code> message MUST NOT use the <code>MSG_TXV5</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 the name <code>MSG_TXV5</code> does not imply that this inv type cannot be used for future transaction versions after v5. New inv types might be added for future transaction versions, but only as needed.</p>
|
<p>Note that the name <code>MSG_TXV5</code> does not imply that this inv type will not be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified. New inv types might be added for future transaction versions, but only as needed.</p>
|
||||||
<p><code>MSG_TX</code> and <code>MSG_TXV5</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><code>MSG_TX</code> and <code>MSG_TXV5</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>
|
<p><strong>Open issue:</strong></p>
|
||||||
<ul>
|
<ul>
|
||||||
|
|
16
zip-0239.rst
16
zip-0239.rst
|
@ -49,7 +49,9 @@ the encoding of which is the same in block data and in the peer-to-peer protocol
|
||||||
|
|
||||||
For v5 transactions, a new transaction digest algorithm is defined that constructs
|
For v5 transactions, a new transaction digest algorithm is defined that constructs
|
||||||
the txid from a tree of hashes, which include only effecting data [#zip-0244]_.
|
the txid from a tree of hashes, which include only effecting data [#zip-0244]_.
|
||||||
Witness data is committed to by a separate "authorizing digest".
|
Witness data is committed to by a separate "authorizing digest". Unlike previous
|
||||||
|
transaction versions, the format of serialized v5 transaction data is not
|
||||||
|
consensus-critical.
|
||||||
|
|
||||||
Not committing to the witness data in v5 transaction announcements would create
|
Not committing to the witness data in v5 transaction announcements would create
|
||||||
inefficiencies: because a v5 transaction's witness can be malleated without altering
|
inefficiencies: because a v5 transaction's witness can be malleated without altering
|
||||||
|
@ -81,19 +83,19 @@ Specification
|
||||||
A new inv type ``MSG_TXV5`` (0x00000005) is added, for use in both ``inv`` messages
|
A new inv type ``MSG_TXV5`` (0x00000005) is added, for use in both ``inv`` messages
|
||||||
and ``getdata`` requests, indicating that the hash being referenced is the 64-byte
|
and ``getdata`` requests, indicating that the hash being referenced is the 64-byte
|
||||||
value ``txid`` || ``auth_digest``. This inv type MUST be used when announcing v5
|
value ``txid`` || ``auth_digest``. This inv type MUST be used when announcing v5
|
||||||
transactions, and only for such transactions. The ``txid`` and ``auth_digest`` are
|
transactions. The ``txid`` and ``auth_digest`` are as defined in [#zip-0244]_.
|
||||||
as defined in [#zip-0244]_.
|
|
||||||
|
|
||||||
In the case of ``getdata`` requests, the format of a v5 transaction obtained by a
|
In the case of ``getdata`` requests, the format of a v5 transaction obtained by a
|
||||||
``MSG_TXV5`` inv type is as given in the Zcash protocol specification.
|
``MSG_TXV5`` inv type is as given in the Zcash protocol specification.
|
||||||
[#protocol-txnencodingandconsensus]_
|
[#protocol-txnencodingandconsensus]_
|
||||||
|
|
||||||
An ``inv`` or ``getdata`` message MUST NOT use the ``MSG_TXV5`` inv type for v4
|
An ``inv`` or ``getdata`` message MUST NOT use the ``MSG_TXV5`` inv type for v4
|
||||||
transactions, or on peer connections that have not negotiated at least the peer
|
or earlier transactions, or on peer connections that have not negotiated at least
|
||||||
protocol version specified in `Deployment`_.
|
the peer protocol version specified in `Deployment`_.
|
||||||
|
|
||||||
Note that the name ``MSG_TXV5`` does not imply that this inv type cannot be used
|
Note that the name ``MSG_TXV5`` does not imply that this inv type will not be used
|
||||||
for future transaction versions after v5. New inv types might be added for future
|
for future transaction versions after v5. Since such versions are not currently
|
||||||
|
consensus-valid, this is left unspecified. New inv types might be added for future
|
||||||
transaction versions, but only as needed.
|
transaction versions, but only as needed.
|
||||||
|
|
||||||
``MSG_TX`` and ``MSG_TXV5`` entries may be mixed in arbitrary order in an ``inv``
|
``MSG_TX`` and ``MSG_TXV5`` entries may be mixed in arbitrary order in an ``inv``
|
||||||
|
|
Loading…
Reference in New Issue