From 60485864f932ba961f8329780a109c6e8f15477e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 17 Mar 2020 15:15:24 +0000 Subject: [PATCH] ZIP 202: "version group id" -> "version group ID" Signed-off-by: Daira Hopwood --- zip-0202.html | 24 ++++++++++++------------ zip-0202.rst | 39 +++++++++++++++++++++++++-------------- 2 files changed, 37 insertions(+), 26 deletions(-) diff --git a/zip-0202.html b/zip-0202.html index 8e9c57cd..2657d2c5 100644 --- a/zip-0202.html +++ b/zip-0202.html @@ -145,7 +145,7 @@ License: MIT >= 3 nVersionGroupId - version group id (not zero) + version group ID (not zero) uint32 @@ -260,12 +260,12 @@ License: MIT

Overwinter parsers will accept the transaction as valid as the most significant bit of the header has been set. By masking off (unsetting) the most significant bit, the parser can retrieve the transaction version number:

0x80000003 & 0x7FFFFFFF = 0x00000003 = 3
-

Version Group Id

-

The version group id is a non-zero, random and unique identifier, of type uint32, assigned to a transaction format version, or a group of soft-forking transaction format versions. The version group id helps nodes disambiguate between consensus branches using the same version number.

-

That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another consensus branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own unique version group id, so that they can reject v3 transactions with unknown version group ids.

-

The combination of transaction version and version group id, nVersion || nVersionGroupId, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed.

-

By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group id will be assigned to that transaction version.

-

However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group id MAY be re-used.

+

Version Group ID

+

The version group ID is a non-zero, random and unique identifier, of type uint32, assigned to a transaction format version, or a group of soft-forking transaction format versions. The version group ID helps nodes disambiguate between consensus branches using the same version number.

+

That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another consensus branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own unique version group ID, so that they can reject v3 transactions with unknown version group IDs.

+

The combination of transaction version and version group ID, nVersion || nVersionGroupId, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed.

+

By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group ID will be assigned to that transaction version.

+

However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.

Expiry Height

The expiry height field, as defined in the Transaction Expiry ZIP 5, stores the block height after which a transaction can no longer be mined.

@@ -275,13 +275,13 @@ License: MIT

A valid Overwinter transaction intended for Zcash MUST have:

  • version number 3; and
    • -
  • version group id 0x03C48270 6; and
    • +
  • version group ID 0x03C48270 6; and
  • fOverwintered flag set.

Overwinter validators MUST reject transactions for violating consensus rules if:

  • the fOverwintered flag is not set; or
    • -
  • the version group id is unknown; or
    • +
  • the version group ID is unknown; or
  • the version number is unknown.

Validation of version 3 transactions MUST use the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP 2.

@@ -296,7 +296,7 @@ License: MIT ... } } -

When (de)serializing v3 transactions, the version group id must also be checked in case the transaction is intended for a consensus branch which has a different format for its version 3 transaction:

+

When (de)serializing v3 transactions, the version group ID must also be checked in case the transaction is intended for a consensus branch which has a different format for its version 3 transaction:

if (tx.nVersion == 3 && tx.nVersionGroupId == OVERWINTER_VERSION_GROUP_ID) {
     auto expiryHeight = tx.nExpiryHeight;
 }
@@ -316,7 +316,7 @@ License: MIT // Valid v3 format transaction intended for this client's chain }

It is expected that this test involving nVersionGroupId is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.

-

However, it's possible that a clone of Zcash is using the same version group id and passes the conditional.

+

However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.

Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP 2.

@@ -325,7 +325,7 @@ License: MIT

Backwards compatibility

This proposal intentionally creates what is known as a "bilateral consensus rule change" 3 between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.

-

Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group ids.

+

Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group IDs.

Reference Implementation

https://github.com/zcash/zcash/pull/2925

diff --git a/zip-0202.rst b/zip-0202.rst index 7a1af147..13e0f87c 100644 --- a/zip-0202.rst +++ b/zip-0202.rst @@ -81,7 +81,7 @@ Version Field Description Type - ``fOverwintered`` flag (bit 31, always set) - ``nVersion`` (bits 30-0) ->= 3 ``nVersionGroupId`` version group id (not zero) ``uint32`` +>= 3 ``nVersionGroupId`` version group ID (not zero) ``uint32`` >= 1 ``tx_in_count`` variable-length integer ``compactSize`` >= 1 ``tx_in`` list of inputs ``vector`` >= 1 ``tx_out_count`` variable-length integer ``compactSize`` @@ -146,24 +146,29 @@ Overwinter parsers will accept the transaction as valid as the most significant 0x80000003 & 0x7FFFFFFF = 0x00000003 = 3 -Version Group Id +Version Group ID ---------------- -The version group id is a non-zero, random and unique identifier, of type ``uint32``, assigned +The version group ID is a non-zero, random and unique identifier, of type ``uint32``, assigned to a transaction format version, or a group of soft-forking transaction format versions. The -version group id helps nodes disambiguate between consensus branches using the same version number. +version group ID helps nodes disambiguate between consensus branches using the same version number. That is, it prevents a client on one branch of the network from attempting to parse transactions intended for another consensus branch, in the situation where the transactions share the same format version number but are actually specified differently. For example, Zcash and a clone of Zcash might both define their own custom v3 transaction formats, but each will have its own -unique version group id, so that they can reject v3 transactions with unknown version group ids. +unique version group ID, so that they can reject v3 transactions with unknown version group IDs. -The combination of transaction version and version group id, ``nVersion || nVersionGroupId``, uniquely defines the transaction format, thus enabling parsers to reject transactions from outside the client's chain which cannot be parsed. +The combination of transaction version and version group ID, ``nVersion || nVersionGroupId``, +uniquely defines the transaction format, thus enabling parsers to reject transactions from outside +the client's chain which cannot be parsed. -By convention, it is expected that when introducing a new transaction version requiring a network upgrade, a new unique version group id will be assigned to that transaction version. +By convention, it is expected that when introducing a new transaction version requiring a network +upgrade, a new unique version group ID will be assigned to that transaction version. -However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group id MAY be re-used. +However, if a new transaction version can be correctly parsed according to the format of a +preceding version (that is, it only restricts the format, or defines fields that were previously +reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used. Expiry Height ------------- @@ -176,13 +181,13 @@ Transaction Validation A valid Overwinter transaction intended for Zcash MUST have: - version number 3; and -- version group id 0x03C48270 [#versiongroupid]_; and +- version group ID 0x03C48270 [#versiongroupid]_; and - ``fOverwintered`` flag set. Overwinter validators MUST reject transactions for violating consensus rules if: - the ``fOverwintered`` flag is not set; or -- the version group id is unknown; or +- the version group ID is unknown; or - the version number is unknown. Validation of version 3 transactions MUST use the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_. @@ -205,7 +210,7 @@ Tests can continue to check for the existence of forwards-compatible transaction } } -When (de)serializing v3 transactions, the version group id must also be checked in case the +When (de)serializing v3 transactions, the version group ID must also be checked in case the transaction is intended for a consensus branch which has a different format for its version 3 transaction:: @@ -239,7 +244,7 @@ To test if the format of an Overwinter transaction is both v3 and the transactio It is expected that this test involving ``nVersionGroupId`` is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system. -However, it's possible that a clone of Zcash is using the same version group id and passes the conditional. +However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional. Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature verification process detailed in the Transaction Signature Verification for Overwinter ZIP [#zip-0143]_. @@ -251,9 +256,15 @@ This proposal will be deployed with the Overwinter network upgrade. The activati Backwards compatibility ======================= -This proposal intentionally creates what is known as a "bilateral consensus rule change" [#zip-0200]_ between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid. +This proposal intentionally creates what is known as a "bilateral consensus rule change" +[#zip-0200]_ between pre-Overwinter software and Overwinter-compatible software. Use of +this new transaction format requires that all network participants upgrade their software +to a compatible version within the upgrade window. Pre-Overwinter software will treat +Overwinter transactions as invalid. -Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group ids. +Once Overwinter has activated, Overwinter-compatible software will reject version 1 and +version 2 transactions, and will only accept transactions based upon supported transaction +version numbers and recognized version group IDs. Reference Implementation