ZIP: 0
Title: ZIP Process
diff --git a/zip-0032.html b/zip-0032.html
index 132ee477..c63810b7 100644
--- a/zip-0032.html
+++ b/zip-0032.html
@@ -4,14 +4,14 @@
- zip-0032
+ ZIP 32: Shielded Hierarchical Deterministic Wallets
-
+
ZIP: 32
Title: Shielded Hierarchical Deterministic Wallets
diff --git a/zip-0143.html b/zip-0143.html
index 6ef13903..e6ac1fac 100644
--- a/zip-0143.html
+++ b/zip-0143.html
@@ -4,7 +4,7 @@
- zip-0143
+ ZIP 143: Transaction Signature Verification for Overwinter
-
+
ZIP: 143
Title: Transaction Signature Verification for Overwinter
diff --git a/zip-0200.html b/zip-0200.html
index 243c2417..ef1433d1 100644
--- a/zip-0200.html
+++ b/zip-0200.html
@@ -4,7 +4,7 @@
- zip-0200
+ ZIP 200: Network Upgrade Mechanism
-
+
ZIP: 200
Title: Network Upgrade Mechanism
diff --git a/zip-0201.html b/zip-0201.html
index e2123a9f..d9cbe57c 100644
--- a/zip-0201.html
+++ b/zip-0201.html
@@ -4,14 +4,14 @@
- zip-0201
+ ZIP 201: Network Peer Management for Overwinter
-
+
ZIP: 201
Title: Network Peer Management for Overwinter
diff --git a/zip-0202.html b/zip-0202.html
index ef5419a5..b5880670 100644
--- a/zip-0202.html
+++ b/zip-0202.html
@@ -4,14 +4,14 @@
- zip-0202
+ ZIP 202: Version 3 Transaction Format for Overwinter
-
+
ZIP: 202
Title: Version 3 Transaction Format for Overwinter
diff --git a/zip-0203.html b/zip-0203.html
index bdf8908d..1eec3bee 100644
--- a/zip-0203.html
+++ b/zip-0203.html
@@ -4,14 +4,14 @@
- zip-0203
+ ZIP 203: Transaction Expiry
-
+
ZIP: 203
Title: Transaction Expiry
diff --git a/zip-0205.html b/zip-0205.html
index f3950642..c809482a 100644
--- a/zip-0205.html
+++ b/zip-0205.html
@@ -4,14 +4,14 @@
- zip-0205
+ ZIP 205: Deployment of the Sapling Network Upgrade
-
+
ZIP: 205
Title: Deployment of the Sapling Network Upgrade
diff --git a/zip-0206.html b/zip-0206.html
index c1c6e1e0..d2251f71 100644
--- a/zip-0206.html
+++ b/zip-0206.html
@@ -4,14 +4,14 @@
- zip-0206
+ ZIP 206: Deployment of the Blossom Network Upgrade
-
+
ZIP: 206
Title: Deployment of the Blossom Network Upgrade
diff --git a/zip-0207.html b/zip-0207.html
index ffb6141c..414edd20 100644
--- a/zip-0207.html
+++ b/zip-0207.html
@@ -4,7 +4,7 @@
- zip-0207
+ ZIP 207: Split Founders' Reward
-
+
ZIP: 207
Title: Split Founders' Reward
diff --git a/zip-0208.html b/zip-0208.html
index a016f013..f143d200 100644
--- a/zip-0208.html
+++ b/zip-0208.html
@@ -1,10 +1,19 @@
-
+
-
-
+
+
+
+ ZIP 208: Shorter Block Target Spacing
+
+
- ZIP: 208
+ZIP: 208
Title: Shorter Block Target Spacing
Owners: Daira Hopwood <daira@electriccoin.co>
Original-Authors: Daira Hopwood <daira@electriccoin.co>
@@ -12,172 +21,137 @@ Original-Authors: Daira Hopwood <daira@electriccoin.co>
Status: Implemented
Category: Consensus
Created: 2019-01-10
-License: MIT
-
- Terminology
- The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 3
- The terms "block chain", "consensus rule change", "branch", and "network upgrade" are to be interpreted as defined in 4.
- The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given 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 1.)
-
-
- Abstract
- This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade 6.
- 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
- The motivations for decreasing the block target spacing are:
-
- - Reduced latency for considering transactions to be sufficiently confirmed;
- - 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 verification and propagation time for a block remain small compared to the block target spacing. See 7 for further analysis in various attack models.
-
-
- Specification
- The changes described in this section are to be made in 1, 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.
- 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 6.
- 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.
- Define:
-
- - BlossomPoWTargetSpacingRatio := PreBlossomPoWTargetSpacing / PostBlossomPoWTargetSpacing
- - PostBlossomHalvingInterval := floor(PreBlossomHalvingInterval · BlossomPoWTargetSpacingRatio).
-
- In the same section, redefine PoWTargetSpacing as a function taking a height parameter, as follows:
-
- - PoWTargetSpacing(height) :=
-
- - PreBlossomPoWTargetSpacing, if not IsBlossomActivated(height)
- - PostBlossomPoWTargetSpacing, otherwise.
-
-
-
- Also redefine AveragingWindowTimespan, MinActualTimespan, MaxActualTimespan, ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
-
- - add a height parameter to each of these functions that does not already have one;
- - ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the height parameter.
-
- In 1 section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the Halving and BlockSubsidy functions as follows:
-
- - Halving(height) :=
-
- - floor((height - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(height)
- - floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (height - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise
-
-
- - BlockSubsidy(height) :=
-
- - SlowStartRate · height, if height < SlowStartInterval / 2
- - SlowStartRate · (height + 1), if SlowStartInterval / 2 ≤ height and height < SlowStartInterval
- - floor(MaxBlockSubsidy / 2Halving(*height*)), if SlowStartInterval ≤ height and not IsBlossomActivated(height)
- - floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2Halving(*height*))), otherwise
-
-
-
- TODO: ideally, BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTargetSpacing should be chosen so that:
-
- - (BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (height - BlossomActivationHeight) / PostBlossomHalvingInterval) is exactly 1 for some integer height.
- - MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2Halving(*height*)) is an integer for the next few periods.
-
- In 1 section 7.8 (Payment of Founders’ Reward), define:
-
- - FounderAddressAdjustedHeight(height) :=
-
- - height, if not IsBlossomActivated(height)
- - BlossomActivationHeight + floor((height - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise
-
-
-
- and in the definition of FounderAddressIndex, replace the use of height with FounderAddressAdjustedHeight(height).
- Also define:
-
- - FoundersRewardLastBlockHeight := max({ height ⦂ N | Halving(height) < 1 })
-
- Replace the first note in that section with:
-
- - No Founders’ Reward is required to be paid for height > FoundersRewardLastBlockHeight (i.e. after the first halving), or for height = 0 (i.e. the genesis block).
-
- and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with FoundersRewardLastBlockHeight.
-
-
- Effect on difficulty adjustment
- 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 5, when the block time exceeds 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 1 section 5.3).
- 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.
-
-
-
- Non-consensus node behaviour
-
- End-of-Service halt
- zcashd implements an "End-of-Service halt" behaviour that halts the node at a block height that corresponds approximately to a given time after release. This interval SHOULD be adjusted in releases where the End-of-Service halt time will follow Blossom activation.
-
-
- Default expiry delta
- When not overridden by the -txexpirydelta option, zcashd RPC calls that create transactions use a default value for the number of blocks after which a transaction will expire. The default in recent versions of zcashd is 20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 50 minutes.
- This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after Blossom activation, to maintain the approximate expiry time of 50 minutes.
- If the -txexpirydelta option is set, then the set value SHOULD be used both before and after Blossom activation.
-
-
- Fingerprinting mitigation
- A "fingerprinting attack" is a network analysis technique in which nodes are identified across network sessions, for example using information about which blocks they request or send.
- zcashd inherits from Bitcoin Core the following behaviour, described in a comment in main.cpp, intended as a fingerprinting mitigation:
- // To prevent fingerprinting attacks, only send blocks outside of the active
+License: MIT
+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", "branch", and "network upgrade" are to be interpreted as defined in2.
+The term "block target spacing" means the time interval between blocks targeted by the difficulty adjustment algorithm in a given branch. It is normally measured in seconds. (This is also sometimes called the "target block time", but "block target spacing" is the term used in3.)
+Abstract
+This proposal specifies a change in the block target spacing, to take effect in the Blossom network upgrade4.
+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
+The motivations for decreasing the block target spacing are:
+
+- Reduced latency for considering transactions to be sufficiently confirmed;
+- 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 verification and propagation time for a block remain small compared to the block target spacing. See5 for further analysis in various attack models.
+Specification
+The changes described in this section are to be made in6, 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 from7 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 in8.
+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.
+Define:
+
+- BlossomPoWTargetSpacingRatio := PreBlossomPoWTargetSpacing / PostBlossomPoWTargetSpacing
+- PostBlossomHalvingInterval := floor(PreBlossomHalvingInterval · BlossomPoWTargetSpacingRatio).
+
+In the same section, redefine PoWTargetSpacing as a function taking a height parameter, as follows:
+
+- PoWTargetSpacing(height) :=
+
+- PreBlossomPoWTargetSpacing, if not IsBlossomActivated(height)
+- PostBlossomPoWTargetSpacing, otherwise.
+
+
+Also redefine AveragingWindowTimespan, MinActualTimespan, MaxActualTimespan, ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows:
+
+- add a height parameter to each of these functions that does not already have one;
+- ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the height parameter.
+
+In9 section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the Halving and BlockSubsidy functions as follows:
+
+- Halving(height) :=
+
+- floor((height - SlowStartShift) / PreBlossomHalvingInterval), if not IsBlossomActivated(height)
+- floor((BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (height - BlossomActivationHeight) / PostBlossomHalvingInterval), otherwise
+
+- BlockSubsidy(height) :=
+
+- SlowStartRate · height, if height < SlowStartInterval / 2
+- SlowStartRate · (height + 1), if SlowStartInterval / 2 ≤ height and height < SlowStartInterval
+- floor(MaxBlockSubsidy / 2Halving(*height*)), if SlowStartInterval ≤ height and not IsBlossomActivated(height)
+- floor(MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2Halving(*height*))), otherwise
+
+
+TODO: ideally, BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTargetSpacing should be chosen so that:
+
+- (BlossomActivationHeight - SlowStartShift) / PreBlossomHalvingInterval + (height - BlossomActivationHeight) / PostBlossomHalvingInterval) is exactly 1 for some integer height.
+- MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2Halving(*height*)) is an integer for the next few periods.
+
+In10 section 7.8 (Payment of Founders’ Reward), define:
+
+- FounderAddressAdjustedHeight(height) :=
+
+- height, if not IsBlossomActivated(height)
+- BlossomActivationHeight + floor((height - BlossomActivationHeight) / BlossomPoWTargetSpacingRatio), otherwise
+
+
+and in the definition of FounderAddressIndex, replace the use of height with FounderAddressAdjustedHeight(height).
+Also define:
+
+- FoundersRewardLastBlockHeight := max({ height ⦂ N | Halving(height) < 1 })
+
+Replace the first note in that section with:
+
+- No Founders’ Reward is required to be paid for height > FoundersRewardLastBlockHeight (i.e. after the first halving), or for height = 0 (i.e. the genesis block).
+
+and in the second note, replace SlowStartShift + PreBlossomHalvingInterval - 1 with FoundersRewardLastBlockHeight.
+Effect on difficulty adjustment
+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 in11, when the block time exceeds 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 (see12 section 5.3).
+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.
+Non-consensus node behaviour
+End-of-Service halt
+zcashd implements an "End-of-Service halt" behaviour that halts the node at a block height that corresponds approximately to a given time after release. This interval SHOULD be adjusted in releases where the End-of-Service halt time will follow Blossom activation.
+Default expiry delta
+When not overridden by the -txexpirydelta option, zcashd RPC calls that create transactions use a default value for the number of blocks after which a transaction will expire. The default in recent versions of zcashd is 20 blocks, which at the pre-Blossom block target spacing corresponds to roughly 50 minutes.
+This default SHOULD change to BlossomPoWTargetSpacingRatio · 20 blocks after Blossom activation, to maintain the approximate expiry time of 50 minutes.
+If the -txexpirydelta option is set, then the set value SHOULD be used both before and after Blossom activation.
+Fingerprinting mitigation
+A "fingerprinting attack" is a network analysis technique in which nodes are identified across network sessions, for example using information about which blocks they request or send.
+zcashd inherits from Bitcoin Core the following behaviour, described in a comment in main.cpp, intended as a fingerprinting mitigation:
+// To prevent fingerprinting attacks, only send blocks outside of the active
// 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 1 section 7.6.5, 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
- zcashd previously did this monitoring every 150 seconds; it is now done every 60 seconds.
-
-
- Block timeout
- The timeout for a requested block is calculated as the target block time, multiplied by 2 + (the number of queued validated headers)/2.
-
-
- Latency optimization when requesting blocks
- When zcashd sees an announced block that chains from headers that it does not already have, it will first ask for the headers, and then the block itself. A latency optimization is performed only if the chain is "nearly synced":
- // First request the headers preceding the announced block. In the normal fully-synced
+// 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 in13 section 7.6.5, 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
+zcashd previously did this monitoring every 150 seconds; it is now done every 60 seconds.
+Block timeout
+The timeout for a requested block is calculated as the target block time, multiplied by 2 + (the number of queued validated headers)/2.
+Latency optimization when requesting blocks
+When zcashd sees an announced block that chains from headers that it does not already have, it will first ask for the headers, and then the block itself. A latency optimization is performed only if the chain is "nearly synced":
+// First request the headers preceding the announced block. In the normal fully-synced
// case where a new block is announced that succeeds the current tip (no reorganization),
// there are no such headers.
// Secondly, and only when we are close to being synced, we request the announced block directly,
// to avoid an extra round-trip. Note that we must *first* ask for the headers, so by the
// time the block arrives, the header chain leading up to it is already validated. Not
// doing this will result in the received block being rejected as an orphan in case it is
-// not a direct successor.
- The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In zcashd this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.
-
-
- Response to getblocks message when pruning
- If pruning is enabled, when zcashd responds to an "getblocks" peer-to-peer message, it will only include blocks that it has on disk, and is likely to still have on disk an hour after responding to the message:
- // If pruning, don't inv blocks unless we have on disk and are likely to still have
-// for some reasonable time window (1 hour) that block relay might require.
- For each block, when estimating whether it will still be on disk after an hour, we take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected in one hour at the target block spacing as of that block. Around Blossom activation, this might underestimate the number of blocks in the next hour, but given the value of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.
-
-
- Estimation of fully synced chain height
- zcashd uses the EstimateNetHeight function to estimate the approximate height of the fully synced chain, so that the progress of block download can be displayed to the node operator. This function has been rewritten, simplified, and changed to take account of cases where the time period that needs to be estimated crosses Blossom activation.
-
-
+The heuristic for "nearly synced" is that the timestamp of the block at the active tip is no more than 20 block times before the current "adjusted time". In zcashd this calculation uses the block target spacing as of the best known header. Around Blossom activation when the block target spacing changes, this could cause the heuristic to be based on the pre-Blossom block target spacing until the node has synced headers past the activation block, but this is not anticipated to cause any problem.
+Response to getblocks message when pruning
+If pruning is enabled, when zcashd responds to an "getblocks" peer-to-peer message, it will only include blocks that it has on disk, and is likely to still have on disk an hour after responding to the message:
+// If pruning, don't inv blocks unless we have on disk and are likely to still have
+// for some reasonable time window (1 hour) that block relay might require.
+For each block, when estimating whether it will still be on disk after an hour, we take MIN_BLOCKS_TO_KEEP = 288 blocks, minus approximately the number of blocks expected in one hour at the target block spacing as of that block. Around Blossom activation, this might underestimate the number of blocks in the next hour, but given the value of MIN_BLOCKS_TO_KEEP, this is not anticipated to cause any problem.
+Estimation of fully synced chain height
+zcashd uses the EstimateNetHeight function to estimate the approximate height of the fully synced chain, so that the progress of block download can be displayed to the node operator. This function has been rewritten, simplified, and changed to take account of cases where the time period that needs to be estimated crosses Blossom activation.
+Other block-related constants
+The following constants, measured in number of blocks, were reviewed and a decision was made not to change them:
+/** The number of blocks within expiry height when a tx is considered to be expiring soon */
TX_EXPIRING_SOON_THRESHOLD = 3
/** Maximum reorg length we will accept before we shut down and alert the user. */
@@ -191,80 +165,32 @@ static const int MAX_BLOCKS_IN_TRANSIT_PER_PEER = 16;
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;
/** Block files containing a block-height within MIN_BLOCKS_TO_KEEP of chainActive.Tip() will not be pruned. */
-static const unsigned int MIN_BLOCKS_TO_KEEP = 288;
-
-
-
-
- Deployment
- This proposal will be deployed with the Blossom network upgrade. 6
-
-
- 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 branch that persists.
-
-
- Reference Implementation
-
-
-
- References
-
-
-
- 1
- Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]
-
-
-
-
-
-
- 2
- Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) [Overwinter+Sapling]
-
-
-
-
-
-
- 3
- Key words for use in RFCs to Indicate Requirement Levels
-
-
-
-
-
-
- 4
- ZIP 200: Network Upgrade Mechanism
-
-
-
-
-
-
- 5
- ZIP 205: Deployment of the Sapling Network Upgrade
-
-
-
-
-
-
- 6
- ZIP 206: Deployment of the Blossom Network Upgrade
-
-
-
-
-
-
- 7
- On Slow and Fast Block Times <https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/>_
-
-
-
-
+static const unsigned int MIN_BLOCKS_TO_KEEP = 288;
+Deployment
+This proposal will be deployed with the Blossom network upgrade.14
+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 branch that persists.
+Reference Implementation
+https://github.com/zcash/zcash/pull/4025
+References
+
+
+
+Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]↩
On Slow and Fast Block Times <https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/>_↩
Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]↩
Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) [Overwinter+Sapling]↩
Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]↩
Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]↩
Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]↩
Zcash Protocol Specification, Version 2019.0.1 or later [Overwinter+Sapling+Blossom]↩
+
-
\ No newline at end of file
+
diff --git a/zip-0209.html b/zip-0209.html
index 5ef07f1b..a807ff8e 100644
--- a/zip-0209.html
+++ b/zip-0209.html
@@ -4,14 +4,14 @@
- zip-0209
+ ZIP 209: Prohibit Negative Shielded Value Pool
-
+
ZIP: 209
Title: Prohibit Negative Shielded Value Pool
diff --git a/zip-0210.html b/zip-0210.html
index 15054e6e..574aedfe 100644
--- a/zip-0210.html
+++ b/zip-0210.html
@@ -4,14 +4,14 @@
- zip-0210
+ ZIP 210: Sapling Anchor Deduplication within Transactions
-
+
ZIP: 210
Title: Sapling Anchor Deduplication within Transactions
diff --git a/zip-0243.html b/zip-0243.html
index fa84bee3..1065a093 100644
--- a/zip-0243.html
+++ b/zip-0243.html
@@ -4,7 +4,7 @@
- zip-0243
+ ZIP 243: Transaction Signature Verification for Sapling
-
+
ZIP: 243
Title: Transaction Signature Verification for Sapling
diff --git a/zip-0308.html b/zip-0308.html
index 599284ea..51d3defc 100644
--- a/zip-0308.html
+++ b/zip-0308.html
@@ -4,14 +4,14 @@
- zip-0308
+ ZIP 308: Sprout to Sapling Migration
-
+
ZIP: 308
Title: Sprout to Sapling Migration
diff --git a/zip-guide.html b/zip-guide.html
index 68806acc..ff04bec7 100644
--- a/zip-guide.html
+++ b/zip-guide.html
@@ -4,14 +4,14 @@
- zip-guide
+ ZIP guide: {Something Short and To the Point}
-
+
ZIP: Unassigned {numbers are assigned by ZIP editors}
Title: {Something Short and To the Point}