From 8c289078cb8df080c4413877a111fe5fbdd9fd06 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 11 Nov 2020 15:30:15 +0000 Subject: [PATCH] Change the specification of minimum-difficulty blocks to reflect the zcashd implementation (which alters nBits rather than just the target threshold). fixes #416 Signed-off-by: Daira Hopwood --- zip-0205.html | 71 +++++++++++++++++++++++++++++++++++++-------------- zip-0205.rst | 44 ++++++++++++++++++------------- zip-0208.html | 62 ++++++++++++++++++++++++++++---------------- zip-0208.rst | 35 +++++++++++++++---------- 4 files changed, 140 insertions(+), 72 deletions(-) diff --git a/zip-0205.html b/zip-0205.html index 771e6878b..d8ce7811c 100644 --- a/zip-0205.html +++ b/zip-0205.html @@ -16,7 +16,8 @@ License: MIT

Terminology

The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1

-

The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 3

+

The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 7

+

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification 3.

The terms below are to be interpreted as follows:

Sapling
@@ -24,18 +25,18 @@

Abstract

-

This proposal defines the deployment of the Sapling network upgrade. In addition, it describes a hard fork that occurred on testnet to allow "minimum-difficulty" blocks.

+

This proposal defines the deployment of the Sapling network upgrade. In addition, it describes a hard fork that occurred on Testnet to allow "minimum-difficulty" blocks.

Specification

Sapling deployment

The primary sources of information about Sapling consensus protocol changes are:

    -
  • The Zcash Protocol Specification 2.
    • -
  • Transaction Signature Validation for Sapling 5.
    • -
  • Network Upgrade Activation Mechanism 3.
    • +
  • The Zcash Protocol Specification 2.
    • +
  • Transaction Signature Validation for Sapling 9.
    • +
  • Network Upgrade Activation Mechanism 7.
-

The network handshake and peer management mechanisms defined in 4 also apply to this upgrade.

-

The following network upgrade constants 3 are defined for the Sapling upgrade:

+

The network handshake and peer management mechanisms defined in 8 also apply to this upgrade.

+

The following network upgrade constants 7 are defined for the Sapling upgrade:

CONSENSUS_BRANCH_ID
0x76b809bb
@@ -45,24 +46,24 @@

Mainnet: 419200

-

On testnet, Sapling had activated prior to this height, but that consensus branch was rolled back. A subsequent hard fork occurred on testnet, changing the difficulty algorithm to accept "minimum-difficulty" blocks under certain conditions starting at block height 299188.

-

On both mainnet and testnet, Sapling-compatible nodes MUST advertise protocol version 170007 or later. The minimum peer protocol version that Sapling-compatible nodes will connect to, remains 170002.

+

On Testnet, Sapling had activated prior to this height, but that consensus branch was rolled back. A subsequent hard fork occurred on Testnet, changing the difficulty algorithm to accept "minimum-difficulty" blocks under certain conditions starting at block height 299188.

+

On both Mainnet and Testnet, Sapling-compatible nodes MUST advertise protocol version 170007 or later. The minimum peer protocol version that Sapling-compatible nodes will connect to, remains 170002.

Pre-Sapling nodes are defined as nodes advertising a protocol version less than 170007.

Approximately three days (defined in terms of block height) before the Sapling activation height, Sapling-compatible nodes will change the behaviour of their peer connection logic in order to prefer pre-Sapling peers for eviction from the set of peer connections.

/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
 static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
-

The implementation is similar to that for Overwinter which was described in 4.

-

Once Sapling activates on testnet or mainnet, Sapling nodes should take steps to:

+

The implementation is similar to that for Overwinter which was described in 8.

+

Once Sapling activates on Testnet or Mainnet, Sapling nodes should take steps to:

  • reject new connections from pre-Sapling nodes;
  • disconnect any existing connections to pre-Sapling nodes.
-

Change to difficulty adjustment on testnet

-

Section 7.6.3 of 2 describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the nTime and nBits fields of preceding blocks.

-

This algorithm changed on testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see 2 section 5.3). However, its nBits field is still computed according to the original difficulty adjustment algorithm.

-

This does not affect how the minimum-difficulty block is treated for subsequent difficulty adjustments. In particular, only the nBits field computed by the original algorithm is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.

-

This change does not affect mainnet.

+

Change to difficulty adjustment on Testnet

+

Section 7.6.3 of the Zcash Protocol Specification 5 describes the algorithm used to adjust the difficulty of a block (defined in terms of a "target threshold") based on the nTime and nBits fields of preceding blocks.

+

This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a minimum-difficulty block. In that case its nBits field is set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification 4, and ToCompact is as defined in section 7.6.4 of that specification 6.

+

Note: a previous revision of this ZIP incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the nBits field is as well, and this affects difficulty adjustment for subsequent blocks.

+

This change does not affect Mainnet.

Backward compatibility

@@ -89,10 +90,42 @@ - +
+ + + +
3Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet
+ + + + + + + +
4Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants
+ + + + + + + +
5Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment
+ + + + + + + +
6Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion
+ + + + @@ -100,7 +133,7 @@
7 ZIP 200: Network Upgrade Activation Mechanism
- + @@ -108,7 +141,7 @@
48 ZIP 201: Network Peer Management for Overwinter
- + diff --git a/zip-0205.rst b/zip-0205.rst index de191b3e3..97fde11b2 100644 --- a/zip-0205.rst +++ b/zip-0205.rst @@ -19,6 +19,9 @@ interpreted as described in RFC 2119. [#RFC2119]_ The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_ +The terms "Testnet" and "Mainnet" are to be interpreted as described in +section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. + The terms below are to be interpreted as follows: Sapling @@ -29,7 +32,7 @@ Abstract ======== This proposal defines the deployment of the Sapling network upgrade. In addition, -it describes a hard fork that occurred on testnet to allow "minimum-difficulty" +it describes a hard fork that occurred on Testnet to allow "minimum-difficulty" blocks. @@ -61,12 +64,12 @@ ACTIVATION_HEIGHT (Sapling) Mainnet: 419200 -On testnet, Sapling had activated prior to this height, but that consensus branch -was rolled back. A subsequent hard fork occurred on testnet, changing the +On Testnet, Sapling had activated prior to this height, but that consensus branch +was rolled back. A subsequent hard fork occurred on Testnet, changing the difficulty algorithm to accept "minimum-difficulty" blocks under certain conditions starting at block height 299188. -On both mainnet and testnet, Sapling-compatible nodes MUST advertise protocol +On both Mainnet and Testnet, Sapling-compatible nodes MUST advertise protocol version 170007 or later. The minimum peer protocol version that Sapling-compatible nodes will connect to, remains 170002. @@ -86,32 +89,33 @@ peer connections. The implementation is similar to that for Overwinter which was described in [#zip-0201]_. -Once Sapling activates on testnet or mainnet, Sapling nodes should take steps to: +Once Sapling activates on Testnet or Mainnet, Sapling nodes should take steps to: - reject new connections from pre-Sapling nodes; - disconnect any existing connections to pre-Sapling nodes. -Change to difficulty adjustment on testnet +Change to difficulty adjustment on Testnet ------------------------------------------ -Section 7.6.3 of [#protocol]_ describes the algorithm used to adjust the difficulty -of a block (defined in terms of a "target threshold") based on the ``nTime`` and -``nBits`` fields of preceding blocks. +Section 7.6.3 of the Zcash Protocol Specification [#protocol-diffadjustment]_ +describes the algorithm used to adjust the difficulty of a block (defined in terms +of a "target threshold") based on the ``nTime`` and ``nBits`` fields of preceding +blocks. -This algorithm changed on testnet, starting from block 299188, to allow +This algorithm changed on Testnet, starting from block 299188, to allow "minimum-difficulty" blocks. If the block time of a block from this height onward is greater than 15 minutes after that of the preceding block, then the block is a -minimum-difficulty block, and its target threshold is set to the value of -PoWLimit for testnet (see [#protocol]_ section 5.3). However, its ``nBits`` field -is still computed according to the original difficulty adjustment algorithm. +minimum-difficulty block. In that case its ``nBits`` field is set to +ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 +of the Zcash Protocol Specification [#protocol-constants]_, and ToCompact is as +defined in section 7.6.4 of that specification [#protocol-nbits]_. -This does not affect how the minimum-difficulty block is treated for subsequent -difficulty adjustments. In particular, only the ``nBits`` field computed by the -original algorithm is used for the purpose of computing the MeanTarget values -from which subsequent difficulty changes are calculated. +Note: a previous revision of this ZIP incorrectly said that only the target +threshold of minimum-difficulty blocks is affected. In fact the ``nBits`` field +is as well, and this affects difficulty adjustment for subsequent blocks. -This change does not affect mainnet. +This change does not affect Mainnet. Backward compatibility @@ -141,6 +145,10 @@ References .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ +.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants `_ +.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment `_ +.. [#protocol-nbits] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion `_ .. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling `_ diff --git a/zip-0208.html b/zip-0208.html index 67fcde89e..18b235207 100644 --- a/zip-0208.html +++ b/zip-0208.html @@ -18,11 +18,12 @@ Pull-Request: <https://github.com/zcash/zips/pull/237>

Terminology

The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1

-

The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in 7.

-

The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification 5.)

+

The terms "block chain", "consensus rule change", "consensus branch", and "network upgrade" are to be interpreted as defined in 9.

+

The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given consensus branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification 6.)

+

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification 4.

Abstract

-

This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade 9.

+

This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade 11.

The emission schedule of mined ZEC will be approximately the same in terms of time, but this requires the emission per block to be adjusted to take account of the changed block target spacing.

Motivation

@@ -32,15 +33,15 @@
  • Greater throughput of transactions in unit time.

    • The latter goal could alternatively be achieved by increasing the block size limit, but that would not also achieve the former goal.

    -

    Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See 11 for further analysis in various attack models.

    +

    Note that, for a given security requirement (in terms of the expected cost distribution of a rollback attack), the number of confirmations needed increases more slowly than the decrease in block time, and so, up to a point, decreasing the block target spacing can provide a better trade-off between latency and security. This argument assumes that the validation and propagation time for a block remain small compared to the block target spacing. See 13 for further analysis in various attack models.

    Specification

    -

    The changes described in this section are to be made in the Zcash Protocol Specification 3, relative to the pre-Blossom specification in [#preblossom-protocol].

    +

    The changes described in this section are to be made in the Zcash Protocol Specification 3, relative to the pre-Blossom specification in [#preblossom-protocol].

    Consensus changes

    -

    Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from 2 of 840000 (blocks) and 150 (seconds) respectively.

    +

    Throughout the specification, rename HalvingInterval to PreBlossomHalvingInterval, and rename PoWTargetSpacing to PreBlossomTargetSpacing. These constants retain their values from 2 of 840000 (blocks) and 150 (seconds) respectively.

    In section 2 (Notation), add BlossomActivationHeight and PostBlossomPoWTargetSpacing to the list of integer constants.

    In section 5.3 (Constants), define PostBlossomPoWTargetSpacing := 75 seconds.

    -

    For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in 9.

    +

    For a given network (production or test), define BlossomActivationHeight as the height at which Blossom activates on that network, as specified in 11.

    In section 7.6.3 (Difficulty adjustment), make the following changes:

    Define IsBlossomActivated(height) to return true if height ≥ BlossomActivationHeight, otherwise false.

    This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.

    @@ -109,10 +110,11 @@

    The difficulty adjustment parameters PoWAveragingWindow and PoWMedianBlockSpan refer to numbers of blocks, but do not change at Blossom activation. This is because the amount of damping/averaging required is expected to be roughly the same, in terms of the number of blocks, after the change in block target spacing.

    The change in the effective value of PoWTargetSpacing will cause the block spacing to adjust to the new target, at the normal rate for a difficulty adjustment. The results of simulations are consistent with this expected behaviour.

    Note that the change in AveragingWindowTimespan(height) takes effect immediately when calculating the target difficulty starting from the block at the Blossom activation height, even though the difficulty of the preceding PoWAveragingWindow blocks will have been adjusted using the pre-Blossom target spacing. Therefore it is likely that the difficulty adjustment for the first few blocks after activation will be limited by PoWMaxAdjustDown. This is not anticipated to cause any problem.

    -

    Minimum difficulty blocks on the test network

    -

    On the test network from block height 299188 onward, the difficulty adjustment algorithm allows minimum-difficulty blocks, as described in 8, when the block time is greater than a given threshold. This specification changes this threshold to be proportional to the block target spacing.

    -

    That is, if the block time of a block at height height ≥ 299188 is at least 6 · PoWTargetSpacing(height) seconds after that of the preceding block, then the block is a minimum-difficulty block, and its target threshold is set to the value of PoWLimit for testnet (see section 5.3 of the Zcash Protocol Specification 4).

    -

    As before, the nBits field of a minimum-difficulty block is still computed according to the original difficulty adjustment algorithm, and only this field is used for the purpose of computing the MeanTarget values from which subsequent difficulty changes are calculated.

    +

    Minimum difficulty blocks on Testnet

    +

    On Testnet from block height 299188 onward, the difficulty adjustment algorithm 6 allows minimum-difficulty blocks, as described in 10, when the block time is greater than a given threshold. This specification changes this threshold to be proportional to the block target spacing.

    +

    That is, if the block time of a block at height height ≥ 299188 is at least 6 · PoWTargetSpacing(height) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its nBits field is set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet in section 5.3 of the Zcash Protocol Specification 5, and ToCompact is as defined in section 7.6.4 of that specification 7.

    +

    Note: a previous revision of this ZIP (and 10) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact the nBits field is as well, and this affects difficulty adjustment for subsequent blocks.

    +

    This change does not affect Mainnet.

    Non-consensus node behaviour

    @@ -125,7 +127,7 @@

    If the -txexpirydelta option is set, then the set value SHOULD be used both before and after Blossom activation.

    Sprout to Sapling migration

    -

    ZIP 308 10 defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.

    +

    ZIP 308 12 defines a procedure for migrating funds from Sprout to Sapling z-addresses. In that procedure, migration transactions are sent every 500 blocks, which corresponded to roughly 20.83 hours before Blossom.

    The 500-block constant has not been changed. Therefore, migration transactions are now sent roughly every 10.42 hours after Blossom activation. This has been noted in the ZIP, and a table showing the expected time to complete migration has been updated accordingly.

    Fingerprinting mitigation

    @@ -135,7 +137,7 @@ // chain if they are valid, and no more than a month older (both in time, and in // best equivalent proof of work) than the best header chain we know about.

    We make no assertion about the significance of fingerprinting for Zcash, and (despite the word "prevent" in the above comment) no claim about the effectiveness of this mitigation.

    -

    In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.6.5 of the Zcash Protocol Specification 6, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.

    +

    In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as defined in section 7.6.5 of the Zcash Protocol Specification 8, divide by the work of the block at the active tip, and multiply by the target block spacing of that block.

    It is not a requirement of the Zcash protocol that this fingerprinting mitigation is used; however, if it is used, then it SHOULD use the target block spacing at the same block height that is used for the current work estimate.

    Monitoring for quicker- or slower-than-expected blocks

    @@ -192,7 +194,7 @@

    Deployment

    -

    This proposal will be deployed with the Blossom network upgrade. 9

    +

    This proposal will be deployed with the Blossom network upgrade. 11

    Backward compatibility

    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 consensus branch that persists.

    @@ -225,10 +227,18 @@
    59 ZIP 243: Transaction Signature Validation for Sapling
    - +
    + + + +
    4Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet
    + + + + @@ -236,15 +246,23 @@
    5 Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants
    - +
    56 Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment
    + + + + + + + +
    7Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion
    - + @@ -252,7 +270,7 @@
    68 Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work
    - + @@ -260,7 +278,7 @@
    79 ZIP 200: Network Upgrade Mechanism
    - + @@ -268,7 +286,7 @@
    810 ZIP 205: Deployment of the Sapling Network Upgrade
    - + @@ -276,7 +294,7 @@
    911 ZIP 206: Deployment of the Blossom Network Upgrade
    - + @@ -284,7 +302,7 @@
    1012 ZIP 308: Sprout to Sapling Migration
    - + diff --git a/zip-0208.rst b/zip-0208.rst index c5669351b..0971b0a79 100644 --- a/zip-0208.rst +++ b/zip-0208.rst @@ -27,6 +27,9 @@ measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in the Zcash Protocol Specification [#protocol-diffadjustment]_.) +The terms "Testnet" and "Mainnet" are to be interpreted as described in +section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. + Abstract ======== @@ -176,24 +179,28 @@ few blocks after activation will be limited by PoWMaxAdjustDown. This is not anticipated to cause any problem. -Minimum difficulty blocks on the test network -''''''''''''''''''''''''''''''''''''''''''''' +Minimum difficulty blocks on Testnet +'''''''''''''''''''''''''''''''''''' -On the test network from block height 299188 onward, the difficulty adjustment -algorithm allows minimum-difficulty blocks, as described in [#zip-0205]_, when -the block time is greater than a given threshold. This specification changes -this threshold to be proportional to the block target spacing. +On Testnet from block height 299188 onward, the difficulty adjustment algorithm +[#protocol-diffadjustment]_ allows minimum-difficulty blocks, as described in +[#zip-0205]_, when the block time is greater than a given threshold. This +specification changes this threshold to be proportional to the block target +spacing. That is, if the block time of a block at height *height* ≥ 299188 is at least 6 · PoWTargetSpacing(*height*) seconds after that of the preceding block, -then the block is a minimum-difficulty block, and its target threshold is set -to the value of PoWLimit for testnet (see section 5.3 of the Zcash Protocol -Specification [#protocol-constants]_). +then the block is a minimum-difficulty block. In that case its ``nBits`` field +is set to ToCompact(PoWLimit), where PoWLimit is the value defined for Testnet +in section 5.3 of the Zcash Protocol Specification [#protocol-constants]_, and +ToCompact is as defined in section 7.6.4 of that specification [#protocol-nbits]_. + +Note: a previous revision of this ZIP (and [#zip-0205]_) incorrectly said that +only the target threshold of minimum-difficulty blocks is affected. In fact +the ``nBits`` field is as well, and this affects difficulty adjustment for +subsequent blocks. -As before, the ``nBits`` field of a minimum-difficulty block is still computed -according to the original difficulty adjustment algorithm, and only this field -is used for the purpose of computing the MeanTarget values from which subsequent -difficulty changes are calculated. +This change does not affect Mainnet. Non-consensus node behaviour @@ -389,8 +396,10 @@ References .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) `_ .. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ .. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants `_ .. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment `_ +.. [#protocol-nbits] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion `_ .. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_
    1113 On Slow and Fast Block Times