From c904f2ebaedfb999e904204d0876e00991524050 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 8 Jan 2018 20:33:08 +0000 Subject: [PATCH 01/32] Draft of network upgrade activation logic ZIP --- drafts/str4d-overwinter-activation/draft1.rst | 179 ++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 drafts/str4d-overwinter-activation/draft1.rst diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst new file mode 100644 index 00000000..842d0e49 --- /dev/null +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -0,0 +1,179 @@ +:: + + ZIP: ??? + Title: Network Upgrade Activation Mechanism + Author: Jack Grigg + Comments-Summary: No comments yet. + Category: Process + Created: 2018-01-08 + License: MIT + + +Terminology +=========== + +The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in +RFC 2119. + + +Abstract +======== + +This proposal defines an activation mechanism for coordinating upgrades of the Zcash network, in order to +remove ambiguity about when network upgrades will activate, provide defined periods in which users should +upgrade their local software, and minimize the risks to both the upgrading network and those users opting out +of the changes. + + +Motivation +========== + +Zcash is a *consensual currency*: nobody is ever going to force someone to use a specific version or a +specific branch of Zcash. [#consensual-currency]_ As such, different sub-communities will always have the +freedom to choose different variants or branches which offer different design trade-offs. + +The current Zcash software includes an *auto-senescence* feature, causing nodes running a particular version +to automatically shut down 16 weeks after that version was released. This was implemented for several reasons +[#release-lifecycle]_: + +- It gives the same systemic advantage of removing old software as auto-upgrade behavior. + +- It requires users to individually choose one of the following options: + + - Upgrade to a more recent software release from the main network. + + - Upgrade to an alternative release. + + - Ignore the "deprecation" and keep running the older software. + +Developers can rely on this cadence for coordinating network upgrades. Once the last pre-upgrade software +version has been deprecated, they can reasonably assume that all node operators on the network either support +the upgraded rules, or have explicitly chosen not to follow them. + +However, this behaviour is not sufficient for performing network upgrades. A globally-understood on-chain +activation mechanism is necessary so that nodes can unambiguously know at what point the changes from an +upgrade come into effect (and can enforce consensus rule changes, for example). + + +Specification +============= + +The following constants are defined for every network upgrade: + +BRANCH_ID + A globally-unique 32-bit identifier. + +ACTIVATION_HEIGHT + The block height at which the network upgrade rules will come into effect, and be enforced as part of the + blockchain consensus. + + For removal of ambiguity, the block at height ``ACTIVATION_HEIGHT - 1`` is subject to the pre-upgrade + consensus rules, and would be the last common block in the event of a persistent pre-upgrade branch. + + It MUST be greater than the value of ``DEPRECATION_HEIGHT`` in the last software version that will not + contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after + the first software version containing support for the network upgrade is released. + +Activation mechanism +-------------------- + +There MUST only be one network upgrade at a time in progress. Concretely, this means that the Zcash blockchain +is broken into "epochs" of block height intervals ``[ACTIVATION_HEIGHT_{N-1}, ACTIVATION_HEIGHT_N)`` (ie. +including ``ACTIVATION_HEIGHT_{N-1}`` and exluding ``ACTIVATION_HEIGHT_N``), on which consensus rule sets are +defined. + +Consensus rules themselves (and any network behavior or surrounding code that depends on them) MUST be gated +by block height checks. For example: + +.. code:: cpp + + if (chainActive.Tip()->nHeight >= OVERWINTER.ACTIVATION_HEIGHT) { + // Overwinter-specific logic + } else { + // Pre-Overwinter logic + } + + // ... + + if (pindex->nHeight >= OVERWINTER.ACTIVATION_HEIGHT) { + // Overwinter consensus rules applied to block + } else { + // Pre-Overwinter consensus rules applied to block + } + + +Block parsing +````````````` +Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be +parsed under the consensus rules corresponding to their height. + +Incoming blocks with unknown heights (because at least one block in their parent chain is unknown) MUST NOT be +considered valid, but MAY be cached for future consideration after all their parents have been received. + +Memory pool +----------- + +While the current chain tip height is below ``ACTIVATION_HEIGHT``, nodes SHOULD NOT accept transactions that +will only be valid on the post-upgrade chain. + +When the current chain tip height reaches ``ACTIVATION_HEIGHT``, the node's local transaction memory pool +SHOULD be cleared. + +Two-way replay protection +------------------------- + +Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the +MSB of the transaction version is set to 1. From the perspective of old nodes, the transactions will have a +negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes +old transactions invalid on the Overwinter branch. + +After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures +committing to a specific ``BRANCH_ID``. [#zip-0143]_ + +Wipe-out protection +------------------- + +Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from +``ACTIVATION_HEIGHT``. The chain from that height will not reorg to a pre-upgrade branch if any block would +violate the new consensus rules (such as including any old-format transaction). + +[TODO: if the non-upgraded chain only had empty blocks, technically that would be valid under new rules, so +could cause a wipe-out. Fixing this would require at least changing the block version, in which case blocks +may as well commit to a ``BRANCH_ID``.] + + +Example +======= + +TBC + + +Deployment +========== + +This proposal will be deployed with the Overwinter network upgrade. + + +Backward compatibility +====================== + +This proposal intentionally creates what is known as a "bilateral hard fork". Use of this mechanism requires +that all network participants upgrade their software to a compatible version within the upgrade window. Older +software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists. + + +Reference Implementation +======================== + +TBC + + +References +========== + +.. [#consensual-currency] https://z.cash/blog/consensual-currency.html +.. [#release-lifecycle] + - https://z.cash/blog/release-cycle-and-lifetimes.html + - https://z.cash/blog/release-cycle-update.html +.. [#roadmap-2018] https://z.cash/blog/roadmap-update-2017-12.html +.. [#zip-0143] Transaction Signature Verification for Overwinter From ed656109f798f7ef5296f988546881728410dded Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 12 Jan 2018 15:06:35 +0100 Subject: [PATCH 02/32] Specify behaviour around chain reorganization and post-activation upgrades --- drafts/str4d-overwinter-activation/draft1.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 842d0e49..20e09dec 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -110,6 +110,24 @@ parsed under the consensus rules corresponding to their height. Incoming blocks with unknown heights (because at least one block in their parent chain is unknown) MUST NOT be considered valid, but MAY be cached for future consideration after all their parents have been received. +Chain reorganization +```````````````````` +It is possible for a reorganization to occur that rolls back from after the activation height, to before that +height. This can handled in the same way as any regular chain orphaning or reorganization, as long as the new +chain is valid over the same epochs. + +Post-activation upgrading +````````````````````````` +If a user does not upgrade their node to a compatible software version before ``ACTIVATION_HEIGHT`` is +reached, their node will follow the pre-upgrade chain and download blocks that are incompatible with the +post-upgrade branch. If the user subsequently upgrades their node to a compatible software version, the node +will consider these blocks to be invalid, and MUST take one of the two following actions: + +- Discard all blocks of height ``ACTIVATION_HEIGHT`` and above, and then synchronize with the network. + +- Shut down and alert the user of the issue. In this case, the node could offer an option to perform the first + action. + Memory pool ----------- From 68cbeafdc672db9fab22c6b0775a36c18eaef354 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 12 Jan 2018 15:07:19 +0100 Subject: [PATCH 03/32] Make the draft about the general mechanism, not specifically activation --- drafts/str4d-overwinter-activation/draft1.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 20e09dec..e79e0bfc 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -1,7 +1,7 @@ :: ZIP: ??? - Title: Network Upgrade Activation Mechanism + Title: Network Upgrade Mechanism Author: Jack Grigg Comments-Summary: No comments yet. Category: Process @@ -19,10 +19,9 @@ RFC 2119. Abstract ======== -This proposal defines an activation mechanism for coordinating upgrades of the Zcash network, in order to -remove ambiguity about when network upgrades will activate, provide defined periods in which users should -upgrade their local software, and minimize the risks to both the upgrading network and those users opting out -of the changes. +This proposal defines a mechanism for coordinating upgrades of the Zcash network, in order to remove ambiguity +about when network upgrades will activate, provide defined periods in which users should upgrade their local +software, and minimize the risks to both the upgrading network and those users opting out of the changes. Motivation From f6664895d51ec7aebb68601f732607f498cd05f4 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 29 Jan 2018 01:27:48 +0000 Subject: [PATCH 04/32] Clarify terminology --- drafts/str4d-overwinter-activation/draft1.rst | 23 +++++++++++++++---- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index e79e0bfc..891b8d4b 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -12,8 +12,21 @@ Terminology =========== -The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in -RFC 2119. +The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as +described in RFC 2119. + +The following terms are interpreted as follows: + +Branch + A chain of blocks with common consensus rules, where the first block in the chain is not the genesis block, + but the child of a parent block created under an older set of consensus rules. + +Hard fork + The creation of a new branch by a change in the consensus rules of the network. Nodes that do not recognize + the new rules will continue to follow the old branch. + +Network Upgrade + An intentional hard fork undertaken by the community in order to improve the network. Abstract @@ -27,9 +40,9 @@ software, and minimize the risks to both the upgrading network and those users o Motivation ========== -Zcash is a *consensual currency*: nobody is ever going to force someone to use a specific version or a -specific branch of Zcash. [#consensual-currency]_ As such, different sub-communities will always have the -freedom to choose different variants or branches which offer different design trade-offs. +Zcash is a *consensual currency*: nobody is ever going to force someone to use a specific software +implementation or a specific branch of Zcash. [#consensual-currency]_ As such, different sub-communities will +always have the freedom to choose different variants or branches which offer different design trade-offs. The current Zcash software includes an *auto-senescence* feature, causing nodes running a particular version to automatically shut down 16 weeks after that version was released. This was implemented for several reasons From 7118a2a90757fba39610298a5181a564dc49c908 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 29 Jan 2018 01:28:44 +0000 Subject: [PATCH 05/32] Reserve the zero-value branch ID for indicating the absence of any upgrade --- drafts/str4d-overwinter-activation/draft1.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 891b8d4b..e9d66d69 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -73,7 +73,10 @@ Specification The following constants are defined for every network upgrade: BRANCH_ID - A globally-unique 32-bit identifier. + A globally-unique non-zero 32-bit identifier. + + Implementations MAY use a value of zero in branch ID fields to indicate the absence of any upgrade (i.e. + that the Sprout consensus rules apply). ACTIVATION_HEIGHT The block height at which the network upgrade rules will come into effect, and be enforced as part of the From 4297d652e990a275a0dbb2fd13850e499ce3515f Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 29 Jan 2018 01:29:16 +0000 Subject: [PATCH 06/32] Explain choice of three-month network upgrade window --- drafts/str4d-overwinter-activation/draft1.rst | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index e9d66d69..4d7788ce 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -87,7 +87,13 @@ ACTIVATION_HEIGHT It MUST be greater than the value of ``DEPRECATION_HEIGHT`` in the last software version that will not contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after - the first software version containing support for the network upgrade is released. + the first software version containing support for the network upgrade is released, for the following reason: + + - As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo + auto-senescence 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade, + version ``X-1`` will deprecate 10 weeks after the release of version ``X``, which is about 2.3 months. A + three-month window provides ample time for users to upgrade their nodes after auto-senescence, and + re-integrate into the network prior to activation of the network upgrade. Activation mechanism -------------------- From 851265c13cac21e27d90ad42a1aa122aefa1a2e8 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 29 Jan 2018 02:58:42 +0000 Subject: [PATCH 07/32] Elaborate on relationship between BRANCH_ID and ACTIVATION_HEIGHT --- drafts/str4d-overwinter-activation/draft1.rst | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 4d7788ce..f425556b 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -95,13 +95,23 @@ ACTIVATION_HEIGHT three-month window provides ample time for users to upgrade their nodes after auto-senescence, and re-integrate into the network prior to activation of the network upgrade. +The relationship between ``BRANCH_ID`` and ``ACTIVATION_HEIGHT`` is many-to-one: it is possible for many +distinct branches to descend from the same parent block (and thus have the same ``ACTIVATION_HEIGHT``), but a +specific branch can only have one parent block. Concretely, this means that if the ``ACTIVATION_HEIGHT`` of a +network upgrade is changed for any reason (e.g. security vulnerabilities or consensus bugs are discovered), +the ``BRANCH_ID`` MUST also be changed. + Activation mechanism -------------------- -There MUST only be one network upgrade at a time in progress. Concretely, this means that the Zcash blockchain -is broken into "epochs" of block height intervals ``[ACTIVATION_HEIGHT_{N-1}, ACTIVATION_HEIGHT_N)`` (ie. -including ``ACTIVATION_HEIGHT_{N-1}`` and exluding ``ACTIVATION_HEIGHT_N``), on which consensus rule sets are -defined. +A blockchain is defined as invalid if, within the set of all network upgrades that have activated in the past +(or will activate in future) on that chain, an ``ACTIVATION_HEIGHT`` is repeated. Note that this does not +require ``ACTIVATION_HEIGHT`` to be globally unique, or even locally unique; multiple network upgrades can +occur in parallel, as long as they are non-overlapping (only one will activate on any given chain). + +Concretely, this means that the Zcash blockchain is broken into "epochs" of block height intervals +``[ACTIVATION_HEIGHT_{N-1}, ACTIVATION_HEIGHT_N)`` (ie. including ``ACTIVATION_HEIGHT_{N-1}`` and excluding +``ACTIVATION_HEIGHT_N``), on which consensus rule sets are defined. Consensus rules themselves (and any network behavior or surrounding code that depends on them) MUST be gated by block height checks. For example: From debf26b3f88cb20bd907d092a7188b48ad682d52 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 29 Jan 2018 03:13:00 +0000 Subject: [PATCH 08/32] Terminology fixes --- drafts/str4d-overwinter-activation/draft1.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index f425556b..9f18aaff 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -150,9 +150,10 @@ chain is valid over the same epochs. Post-activation upgrading ````````````````````````` If a user does not upgrade their node to a compatible software version before ``ACTIVATION_HEIGHT`` is -reached, their node will follow the pre-upgrade chain and download blocks that are incompatible with the -post-upgrade branch. If the user subsequently upgrades their node to a compatible software version, the node -will consider these blocks to be invalid, and MUST take one of the two following actions: +reached, their node will follow any pre-upgrade branch that persists, and may download blocks that are +incompatible with the post-upgrade branch. If the user subsequently upgrades their node to a compatible +software version, the node will consider these blocks to be invalid, and MUST take one of the two following +actions: - Discard all blocks of height ``ACTIVATION_HEIGHT`` and above, and then synchronize with the network. @@ -163,7 +164,7 @@ Memory pool ----------- While the current chain tip height is below ``ACTIVATION_HEIGHT``, nodes SHOULD NOT accept transactions that -will only be valid on the post-upgrade chain. +will only be valid on the post-upgrade branch. When the current chain tip height reaches ``ACTIVATION_HEIGHT``, the node's local transaction memory pool SHOULD be cleared. From f9604ca1dceed2cc27710cb41d4529f4137983f9 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 29 Jan 2018 03:15:48 +0000 Subject: [PATCH 09/32] Clarify mempool clearing behaviour --- drafts/str4d-overwinter-activation/draft1.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 9f18aaff..da02e9c6 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -167,7 +167,7 @@ While the current chain tip height is below ``ACTIVATION_HEIGHT``, nodes SHOULD will only be valid on the post-upgrade branch. When the current chain tip height reaches ``ACTIVATION_HEIGHT``, the node's local transaction memory pool -SHOULD be cleared. +SHOULD be cleared of transactions that will never be valid on the post-upgrade branch. Two-way replay protection ------------------------- From 065a4a6b96d9fb81caefb5e5554e37d9a9368ef3 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 29 Jan 2018 03:23:43 +0000 Subject: [PATCH 10/32] Add details about Overwinter wipe-out protection --- drafts/str4d-overwinter-activation/draft1.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index da02e9c6..8cbbd943 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -187,9 +187,12 @@ Nodes running upgrade-aware software versions will enforce the upgraded consensu ``ACTIVATION_HEIGHT``. The chain from that height will not reorg to a pre-upgrade branch if any block would violate the new consensus rules (such as including any old-format transaction). -[TODO: if the non-upgraded chain only had empty blocks, technically that would be valid under new rules, so -could cause a wipe-out. Fixing this would require at least changing the block version, in which case blocks -may as well commit to a ``BRANCH_ID``.] +Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not +differ. For example, if the non-upgraded chain only had empty blocks, and the coinbase transactions were valid +under both the old and new consensus rules, a wipe-out could occur. The Overwinter network upgrade is not +susceptible to this because all previous transaction versions will become invalid, meaning that the coinbase +transactions must use the newer transaction version. More generally, this issue could be addressed in a future +network upgrade by modifying the block header to include a commitment to the ``BRANCH_ID``. Example From 1f04e2745b6908fc58d02f9bfcc42c0acb72f1ee Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:00:14 +0000 Subject: [PATCH 11/32] Update example to use real network upgrade functions --- drafts/str4d-overwinter-activation/draft1.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 8cbbd943..cda4f1f7 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -118,15 +118,15 @@ by block height checks. For example: .. code:: cpp - if (chainActive.Tip()->nHeight >= OVERWINTER.ACTIVATION_HEIGHT) { + if (CurrentEpoch(chainActive.Height(), Params().GetConsensus()) == Consensus::UPGRADE_OVERWINTER) { // Overwinter-specific logic } else { - // Pre-Overwinter logic + // Non-Overwinter logic } // ... - if (pindex->nHeight >= OVERWINTER.ACTIVATION_HEIGHT) { + if (NetworkUpgradeActive(pindex->nHeight, Params().GetConsensus(), Consensus::UPGRADE_OVERWINTER)) { // Overwinter consensus rules applied to block } else { // Pre-Overwinter consensus rules applied to block From b625ef6cd6544c18058ab3a0e4dc0d7bd2aba2fa Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:01:40 +0000 Subject: [PATCH 12/32] Add reference to Overwinter transaction format ZIP --- drafts/str4d-overwinter-activation/draft1.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index cda4f1f7..3024ff60 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -173,9 +173,9 @@ Two-way replay protection ------------------------- Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the -MSB of the transaction version is set to 1. From the perspective of old nodes, the transactions will have a -negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes -old transactions invalid on the Overwinter branch. +MSB of the transaction version is set to 1. [#zip-tx-format]_ From the perspective of old nodes, the +transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing +this rule trivially makes old transactions invalid on the Overwinter branch. After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific ``BRANCH_ID``. [#zip-0143]_ @@ -229,4 +229,5 @@ References - https://z.cash/blog/release-cycle-and-lifetimes.html - https://z.cash/blog/release-cycle-update.html .. [#roadmap-2018] https://z.cash/blog/roadmap-update-2017-12.html +.. [#zip-tx-format] Overwinter Transaction Format .. [#zip-0143] Transaction Signature Verification for Overwinter From 2717211483bffc9c9f581bf590c021e95068efc4 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:02:03 +0000 Subject: [PATCH 13/32] Clarify action the user is taking when running older software --- drafts/str4d-overwinter-activation/draft1.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 3024ff60..7d50f6df 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -56,7 +56,7 @@ to automatically shut down 16 weeks after that version was released. This was im - Upgrade to an alternative release. - - Ignore the "deprecation" and keep running the older software. + - Modify their node in order to keep running the older software. Developers can rely on this cadence for coordinating network upgrades. Once the last pre-upgrade software version has been deprecated, they can reasonably assume that all node operators on the network either support From 26ca04f8ee11066fe44920d3b358db9e98e1fb05 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:07:04 +0000 Subject: [PATCH 14/32] Add reference to RFC2119 --- drafts/str4d-overwinter-activation/draft1.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 7d50f6df..1457be19 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -13,7 +13,7 @@ Terminology =========== The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as -described in RFC 2119. +described in RFC 2119. [#RFC2119]_ The following terms are interpreted as follows: @@ -224,6 +224,7 @@ TBC References ========== +.. [#RFC2119] https://tools.ietf.org/html/rfc2119 .. [#consensual-currency] https://z.cash/blog/consensual-currency.html .. [#release-lifecycle] - https://z.cash/blog/release-cycle-and-lifetimes.html From 42365e445bfa8e8384eaf270fba57716ea265841 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:15:34 +0000 Subject: [PATCH 15/32] Define DEPRECATION_HEIGHT, clarify that 16 weeks is approximate --- drafts/str4d-overwinter-activation/draft1.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 1457be19..0d3867d7 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -45,8 +45,9 @@ implementation or a specific branch of Zcash. [#consensual-currency]_ As such, d always have the freedom to choose different variants or branches which offer different design trade-offs. The current Zcash software includes an *auto-senescence* feature, causing nodes running a particular version -to automatically shut down 16 weeks after that version was released. This was implemented for several reasons -[#release-lifecycle]_: +to automatically shut down approximately 16 weeks after that version was released (specifically, at the block +height ``DEPRECATION_HEIGHT`` defined in the source code for that version). This was implemented for several +reasons: [#release-lifecycle]_ - It gives the same systemic advantage of removing old software as auto-upgrade behavior. From 25375a5b960f096584b4d0451a313f0e1f7f9afc Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:16:34 +0000 Subject: [PATCH 16/32] ACTIVATION_HEIGHT is non-zero --- drafts/str4d-overwinter-activation/draft1.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 0d3867d7..d6ad5d99 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -80,8 +80,8 @@ BRANCH_ID that the Sprout consensus rules apply). ACTIVATION_HEIGHT - The block height at which the network upgrade rules will come into effect, and be enforced as part of the - blockchain consensus. + The non-zero block height at which the network upgrade rules will come into effect, and be enforced as part + of the blockchain consensus. For removal of ambiguity, the block at height ``ACTIVATION_HEIGHT - 1`` is subject to the pre-upgrade consensus rules, and would be the last common block in the event of a persistent pre-upgrade branch. From 35772f767b9f341d1886db5e6c99e6e92bb19a02 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:16:54 +0000 Subject: [PATCH 17/32] Clarify conditions under which blocks have unknown height --- drafts/str4d-overwinter-activation/draft1.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index d6ad5d99..9684111d 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -139,8 +139,9 @@ Block parsing Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be parsed under the consensus rules corresponding to their height. -Incoming blocks with unknown heights (because at least one block in their parent chain is unknown) MUST NOT be -considered valid, but MAY be cached for future consideration after all their parents have been received. +Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown) +MUST NOT be considered valid, but MAY be cached for future consideration after all their parents have been +received. Chain reorganization ```````````````````` From 7e3439ebb49cd6c946ab628cc5cf5fc8c854b416 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:18:31 +0000 Subject: [PATCH 18/32] Update terms, include genesis-rooted chain in definition of branches --- drafts/str4d-overwinter-activation/draft1.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 9684111d..a726460c 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -15,17 +15,18 @@ Terminology The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ -The following terms are interpreted as follows: +The terms below are to be interpreted as follows: Branch - A chain of blocks with common consensus rules, where the first block in the chain is not the genesis block, - but the child of a parent block created under an older set of consensus rules. + A chain of blocks with common consensus rules, where the first block in the chain is either the genesis + block, or the child of a parent block created under an older set of consensus rules (ie. the parent block is + a member of a different branch). By definition, every block belongs to at most one branch. Hard fork The creation of a new branch by a change in the consensus rules of the network. Nodes that do not recognize the new rules will continue to follow the old branch. -Network Upgrade +Network upgrade An intentional hard fork undertaken by the community in order to improve the network. From 621229a657b61a9e298a1797519252b248f9b21a Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:24:05 +0000 Subject: [PATCH 19/32] Adjust indices for epoch range to be more intuitive The epoch range is now clearly for the upgrade activated at ACTIVATION_HEIGHT_N. --- drafts/str4d-overwinter-activation/draft1.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index a726460c..0231a6b8 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -112,8 +112,8 @@ require ``ACTIVATION_HEIGHT`` to be globally unique, or even locally unique; mul occur in parallel, as long as they are non-overlapping (only one will activate on any given chain). Concretely, this means that the Zcash blockchain is broken into "epochs" of block height intervals -``[ACTIVATION_HEIGHT_{N-1}, ACTIVATION_HEIGHT_N)`` (ie. including ``ACTIVATION_HEIGHT_{N-1}`` and excluding -``ACTIVATION_HEIGHT_N``), on which consensus rule sets are defined. +``[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})`` (ie. including ``ACTIVATION_HEIGHT_N`` and excluding +``ACTIVATION_HEIGHT_{N+1}``), on which consensus rule sets are defined. Consensus rules themselves (and any network behavior or surrounding code that depends on them) MUST be gated by block height checks. For example: From 584292162c5822ed0b4eb89f20307204b3564d2c Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 5 Feb 2018 01:30:04 +0000 Subject: [PATCH 20/32] Clarify wipe-out protection --- drafts/str4d-overwinter-activation/draft1.rst | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 0231a6b8..18cb01db 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -187,15 +187,16 @@ Wipe-out protection ------------------- Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from -``ACTIVATION_HEIGHT``. The chain from that height will not reorg to a pre-upgrade branch if any block would -violate the new consensus rules (such as including any old-format transaction). +``ACTIVATION_HEIGHT``. The chain from that height will not reorg to a pre-upgrade branch if any block in that +branch would violate the new consensus rules (such as including any old-format transaction). Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not -differ. For example, if the non-upgraded chain only had empty blocks, and the coinbase transactions were valid -under both the old and new consensus rules, a wipe-out could occur. The Overwinter network upgrade is not -susceptible to this because all previous transaction versions will become invalid, meaning that the coinbase -transactions must use the newer transaction version. More generally, this issue could be addressed in a future -network upgrade by modifying the block header to include a commitment to the ``BRANCH_ID``. +differ. For example, if the non-upgraded chain only contained empty blocks from ``ACTIVATION_HEIGHT``, and the +coinbase transactions were valid under both the old and new consensus rules, a wipe-out could occur. The +Overwinter network upgrade is not susceptible to this because all previous transaction versions will become +invalid, meaning that the coinbase transactions must use the newer transaction version. More generally, this +issue could be addressed in a future network upgrade by modifying the block header to include a commitment to +the ``BRANCH_ID``. Example From baafbfd54da933dca874f4f678fa167f0deabf66 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 6 Feb 2018 09:47:15 +0000 Subject: [PATCH 21/32] Update URLs --- drafts/str4d-overwinter-activation/draft1.rst | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 18cb01db..43e50836 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -222,7 +222,7 @@ software will treat post-upgrade blocks as invalid, and will follow any pre-upgr Reference Implementation ======================== -TBC +https://github.com/zcash/zcash/pull/2898 References @@ -233,6 +233,5 @@ References .. [#release-lifecycle] - https://z.cash/blog/release-cycle-and-lifetimes.html - https://z.cash/blog/release-cycle-update.html -.. [#roadmap-2018] https://z.cash/blog/roadmap-update-2017-12.html -.. [#zip-tx-format] Overwinter Transaction Format -.. [#zip-0143] Transaction Signature Verification for Overwinter +.. [#zip-tx-format] `Overwinter Transaction Format `_ +.. [#zip-0143] `Transaction Signature Verification for Overwinter `_ From f7d2954e54baae38a1a82753f1c4fcafab40a7cd Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 6 Feb 2018 19:35:36 +0000 Subject: [PATCH 22/32] Grammar and formatting --- drafts/str4d-overwinter-activation/draft1.rst | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 43e50836..2a75f032 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -19,8 +19,8 @@ The terms below are to be interpreted as follows: Branch A chain of blocks with common consensus rules, where the first block in the chain is either the genesis - block, or the child of a parent block created under an older set of consensus rules (ie. the parent block is - a member of a different branch). By definition, every block belongs to at most one branch. + block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block + is a member of a different branch). By definition, every block belongs to at most one branch. Hard fork The creation of a new branch by a change in the consensus rules of the network. Nodes that do not recognize @@ -93,8 +93,8 @@ ACTIVATION_HEIGHT - As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo auto-senescence 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade, - version ``X-1`` will deprecate 10 weeks after the release of version ``X``, which is about 2.3 months. A - three-month window provides ample time for users to upgrade their nodes after auto-senescence, and + version ``X-1`` will be deprecated 10 weeks after the release of version ``X``, which is about 2.3 months. + A three-month window provides ample time for users to upgrade their nodes after auto-senescence, and re-integrate into the network prior to activation of the network upgrade. The relationship between ``BRANCH_ID`` and ``ACTIVATION_HEIGHT`` is many-to-one: it is possible for many @@ -112,7 +112,7 @@ require ``ACTIVATION_HEIGHT`` to be globally unique, or even locally unique; mul occur in parallel, as long as they are non-overlapping (only one will activate on any given chain). Concretely, this means that the Zcash blockchain is broken into "epochs" of block height intervals -``[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})`` (ie. including ``ACTIVATION_HEIGHT_N`` and excluding +``[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})`` (i.e. including ``ACTIVATION_HEIGHT_N`` and excluding ``ACTIVATION_HEIGHT_{N+1}``), on which consensus rule sets are defined. Consensus rules themselves (and any network behavior or surrounding code that depends on them) MUST be gated @@ -176,9 +176,9 @@ Two-way replay protection ------------------------- Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the -MSB of the transaction version is set to 1. [#zip-tx-format]_ From the perspective of old nodes, the -transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing -this rule trivially makes old transactions invalid on the Overwinter branch. +most significant bit of the transaction version is set to 1. [#zip-tx-format]_ From the perspective of old +nodes, the transactions will have a negative version number, which is invalid under the old consensus rules. +Enforcing this rule trivially makes old transactions invalid on the Overwinter branch. After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific ``BRANCH_ID``. [#zip-0143]_ @@ -187,8 +187,8 @@ Wipe-out protection ------------------- Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from -``ACTIVATION_HEIGHT``. The chain from that height will not reorg to a pre-upgrade branch if any block in that -branch would violate the new consensus rules (such as including any old-format transaction). +``ACTIVATION_HEIGHT``. The chain from that height will not reorganize to a pre-upgrade branch if any block in +that branch would violate the new consensus rules (such as including any old-format transaction). Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not differ. For example, if the non-upgraded chain only contained empty blocks from ``ACTIVATION_HEIGHT``, and the From 3bbbb1036e4df640069712460936538a1ca8b471 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 6 Feb 2018 19:35:59 +0000 Subject: [PATCH 23/32] Remove unnecessary ZIP elements --- drafts/str4d-overwinter-activation/draft1.rst | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 2a75f032..a52251b7 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -3,7 +3,6 @@ ZIP: ??? Title: Network Upgrade Mechanism Author: Jack Grigg - Comments-Summary: No comments yet. Category: Process Created: 2018-01-08 License: MIT @@ -199,12 +198,6 @@ issue could be addressed in a future network upgrade by modifying the block head the ``BRANCH_ID``. -Example -======= - -TBC - - Deployment ========== From 35f33f7a3436ed83b1ca2f62a7bae4413a2d8bc7 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 6 Feb 2018 19:37:05 +0000 Subject: [PATCH 24/32] Clarify statements --- drafts/str4d-overwinter-activation/draft1.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index a52251b7..f3f9630d 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -34,7 +34,7 @@ Abstract This proposal defines a mechanism for coordinating upgrades of the Zcash network, in order to remove ambiguity about when network upgrades will activate, provide defined periods in which users should upgrade their local -software, and minimize the risks to both the upgrading network and those users opting out of the changes. +software, and minimize the risks to both the upgrading network and any users opting out of the changes. Motivation @@ -147,7 +147,7 @@ Chain reorganization ```````````````````` It is possible for a reorganization to occur that rolls back from after the activation height, to before that height. This can handled in the same way as any regular chain orphaning or reorganization, as long as the new -chain is valid over the same epochs. +chain is valid. Post-activation upgrading ````````````````````````` @@ -187,7 +187,7 @@ Wipe-out protection Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from ``ACTIVATION_HEIGHT``. The chain from that height will not reorganize to a pre-upgrade branch if any block in -that branch would violate the new consensus rules (such as including any old-format transaction). +that branch would violate the new consensus rules. Care must be taken, however, to account for possible edge cases where the old and new consensus rules do not differ. For example, if the non-upgraded chain only contained empty blocks from ``ACTIVATION_HEIGHT``, and the From 52e109affc71f41c5df72727f1339350d576e6fa Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 6 Feb 2018 19:50:55 +0000 Subject: [PATCH 25/32] Fix block parsing section to be about block validation --- drafts/str4d-overwinter-activation/draft1.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index f3f9630d..75a3ca62 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -11,7 +11,7 @@ Terminology =========== -The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as +The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ The terms below are to be interpreted as follows: @@ -134,14 +134,13 @@ by block height checks. For example: } -Block parsing -````````````` +Block validation +```````````````` Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be -parsed under the consensus rules corresponding to their height. +validated under the consensus rules corresponding to the expected branch ID for that height. Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown) -MUST NOT be considered valid, but MAY be cached for future consideration after all their parents have been -received. +MAY be cached for future consideration after all their parents have been received. Chain reorganization ```````````````````` From c4bf8a86da72e4cb9e6ebf6974306144e09163c9 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 6 Feb 2018 21:29:26 +0000 Subject: [PATCH 26/32] Allocated number: ZIP 200 --- drafts/str4d-overwinter-activation/draft1.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 75a3ca62..ea121201 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -1,6 +1,6 @@ :: - ZIP: ??? + ZIP: 200 Title: Network Upgrade Mechanism Author: Jack Grigg Category: Process From 1a5ab78f25fce7b1f5c60d443dff7a6b0f792459 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 26 Feb 2018 21:34:22 +0000 Subject: [PATCH 27/32] Terminology: "consensus rule change" --- drafts/str4d-overwinter-activation/draft1.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index ea121201..000d90ca 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -21,12 +21,12 @@ Branch block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block is a member of a different branch). By definition, every block belongs to at most one branch. -Hard fork +Consensus rule change The creation of a new branch by a change in the consensus rules of the network. Nodes that do not recognize the new rules will continue to follow the old branch. Network upgrade - An intentional hard fork undertaken by the community in order to improve the network. + An intentional consensus rule change undertaken by the community in order to improve the network. Abstract @@ -206,9 +206,10 @@ This proposal will be deployed with the Overwinter network upgrade. Backward compatibility ====================== -This proposal intentionally creates what is known as a "bilateral hard fork". Use of this mechanism requires -that all network participants upgrade their software to a compatible version within the upgrade window. Older -software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists. +This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this +mechanism requires that all network participants upgrade their software to a compatible version within the +upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade +branch that persists. Reference Implementation From f1b89467f406e20f214de9bd68f9b4b2267f0319 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 26 Feb 2018 21:35:17 +0000 Subject: [PATCH 28/32] Update category --- drafts/str4d-overwinter-activation/draft1.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 000d90ca..eac10c69 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -3,7 +3,7 @@ ZIP: 200 Title: Network Upgrade Mechanism Author: Jack Grigg - Category: Process + Category: Consensus Created: 2018-01-08 License: MIT From c48da32f5f88f4b69427c32a169018732c8c50bc Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 26 Feb 2018 22:19:15 +0000 Subject: [PATCH 29/32] Clarifications --- drafts/str4d-overwinter-activation/draft1.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index eac10c69..59cb4614 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -114,8 +114,8 @@ Concretely, this means that the Zcash blockchain is broken into "epochs" of bloc ``[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})`` (i.e. including ``ACTIVATION_HEIGHT_N`` and excluding ``ACTIVATION_HEIGHT_{N+1}``), on which consensus rule sets are defined. -Consensus rules themselves (and any network behavior or surrounding code that depends on them) MUST be gated -by block height checks. For example: +When a consensus rule depends on activation of a particular upgrade, its implementation (and that of any +network behavior or surrounding code that depends on it) MUST be gated by a block height check. For example: .. code:: cpp @@ -140,7 +140,7 @@ Incoming blocks known to have a particular height (due to their parent chain bei validated under the consensus rules corresponding to the expected branch ID for that height. Incoming blocks with unknown heights (because at least one block header in their parent chain is unknown) -MAY be cached for future consideration after all their parents have been received. +MAY be cached, so that they can be reconsidered in the future after all their parents have been received. Chain reorganization ```````````````````` From 10f83c790f3c2f435d5da41cf90d1b566d50c6ec Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 28 Feb 2018 22:15:12 +0000 Subject: [PATCH 30/32] Address remaining comments, clean up references --- drafts/str4d-overwinter-activation/draft1.rst | 29 +++++++------------ 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 59cb4614..936d6377 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -81,7 +81,7 @@ BRANCH_ID ACTIVATION_HEIGHT The non-zero block height at which the network upgrade rules will come into effect, and be enforced as part - of the blockchain consensus. + of the block chain consensus. For removal of ambiguity, the block at height ``ACTIVATION_HEIGHT - 1`` is subject to the pre-upgrade consensus rules, and would be the last common block in the event of a persistent pre-upgrade branch. @@ -105,12 +105,7 @@ the ``BRANCH_ID`` MUST also be changed. Activation mechanism -------------------- -A blockchain is defined as invalid if, within the set of all network upgrades that have activated in the past -(or will activate in future) on that chain, an ``ACTIVATION_HEIGHT`` is repeated. Note that this does not -require ``ACTIVATION_HEIGHT`` to be globally unique, or even locally unique; multiple network upgrades can -occur in parallel, as long as they are non-overlapping (only one will activate on any given chain). - -Concretely, this means that the Zcash blockchain is broken into "epochs" of block height intervals +The Zcash block chain is broken into "epochs" of block height intervals ``[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})`` (i.e. including ``ACTIVATION_HEIGHT_N`` and excluding ``ACTIVATION_HEIGHT_{N+1}``), on which consensus rule sets are defined. @@ -153,13 +148,8 @@ Post-activation upgrading If a user does not upgrade their node to a compatible software version before ``ACTIVATION_HEIGHT`` is reached, their node will follow any pre-upgrade branch that persists, and may download blocks that are incompatible with the post-upgrade branch. If the user subsequently upgrades their node to a compatible -software version, the node will consider these blocks to be invalid, and MUST take one of the two following -actions: - -- Discard all blocks of height ``ACTIVATION_HEIGHT`` and above, and then synchronize with the network. - -- Shut down and alert the user of the issue. In this case, the node could offer an option to perform the first - action. +software version, the node will consider these blocks to be invalid, and if there are a significant number of +invalid blocks it SHOULD shut down and alert the user of the issue. Memory pool ----------- @@ -174,8 +164,8 @@ Two-way replay protection ------------------------- Before the Overwinter network upgrade, two-way replay protection is ensured by enforcing post-upgrade that the -most significant bit of the transaction version is set to 1. [#zip-tx-format]_ From the perspective of old -nodes, the transactions will have a negative version number, which is invalid under the old consensus rules. +most significant bit of the transaction version is set to 1. [#zip-0202]_ From the perspective of old nodes, +the transactions will have a negative version number, which is invalid under the old consensus rules. Enforcing this rule trivially makes old transactions invalid on the Overwinter branch. After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures @@ -200,7 +190,7 @@ the ``BRANCH_ID``. Deployment ========== -This proposal will be deployed with the Overwinter network upgrade. +This proposal will be deployed with the Overwinter network upgrade. [#zip-0201]_ Backward compatibility @@ -226,5 +216,6 @@ References .. [#release-lifecycle] - https://z.cash/blog/release-cycle-and-lifetimes.html - https://z.cash/blog/release-cycle-update.html -.. [#zip-tx-format] `Overwinter Transaction Format `_ -.. [#zip-0143] `Transaction Signature Verification for Overwinter `_ +.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter `_ +.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter `_ +.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ From 9eff642696216e5cd53b6a0ce7dab56c6807e330 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 28 Feb 2018 22:16:38 +0000 Subject: [PATCH 31/32] Clarify terminology --- drafts/str4d-overwinter-activation/draft1.rst | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/drafts/str4d-overwinter-activation/draft1.rst index 936d6377..ef8a2f6e 100644 --- a/drafts/str4d-overwinter-activation/draft1.rst +++ b/drafts/str4d-overwinter-activation/draft1.rst @@ -16,14 +16,21 @@ described in RFC 2119. [#RFC2119]_ The terms below are to be interpreted as follows: -Branch - A chain of blocks with common consensus rules, where the first block in the chain is either the genesis - block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block - is a member of a different branch). By definition, every block belongs to at most one branch. +Block chain + A sequence of blocks starting at the genesis block, where the header of each block refers to the previous + block in the sequence. + +Consensus rule set + A set of validation rules that determine which block chains are considered valid. Consensus rule change - The creation of a new branch by a change in the consensus rules of the network. Nodes that do not recognize - the new rules will continue to follow the old branch. + A change in the consensus rule set of the network, such that nodes that do not recognize the new rules will + follow a different block chain. + +Branch + A block chain with a common consensus rule set, where the first block in the chain is either the genesis + block, or the child of a parent block created under an older set of consensus rules (i.e. the parent block + is a member of a different branch). By definition, every block belongs to at most one branch. Network upgrade An intentional consensus rule change undertaken by the community in order to improve the network. From a2d4311da638e86e2533a949266da3e0469ef127 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 28 Feb 2018 22:20:13 +0000 Subject: [PATCH 32/32] Move ZIP 200 out of drafts --- drafts/str4d-overwinter-activation/draft1.rst => zip-0200.rst | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename drafts/str4d-overwinter-activation/draft1.rst => zip-0200.rst (100%) diff --git a/drafts/str4d-overwinter-activation/draft1.rst b/zip-0200.rst similarity index 100% rename from drafts/str4d-overwinter-activation/draft1.rst rename to zip-0200.rst