Terminology 
- The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. 1
-The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 3
+The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", and "REQUIRED" in this document are to be interpreted as described in RFC 2119. 1
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 3
Abstract
A Zcash Improvement Proposal (ZIP) is a design document providing information to the Zcash community, or describing a new feature for Zcash or its processes or environment. The ZIP should provide a concise technical specification of the feature and a rationale for the feature.
@@ -75,7 +75,7 @@ License: BSD-2-ClauseThe ZIP editors monitor ZIP changes and update ZIP headers as appropriate.
The ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons:
-
-
- it violates the Zcash Code of Conduct 4 ; +
- it violates the Zcash Code of Conduct 4 ;
- it appears too unfocused or broad;
- it duplicates effort in other ZIPs without sufficient technical justification (however, alternative proposals to address similar or overlapping problems are not excluded for this reason);
- it has manifest security flaws (including being unrealistically dependent on user vigilance to avoid security weaknesses); @@ -93,17 +93,17 @@ License: BSD-2-Clause
- a new ZIP has been proposed for a category that does not reflect its content, or an update would change a ZIP to an inappropriate category;
- it updates a Released ZIP to Draft when the specification is already implemented and has been in common use;
- it violates any specific "MUST" or "MUST NOT" rule in this document; -
- the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct 4 (except in the case of an update removing that Owner); +
- the expressed political views of a Owner of the document are inimical to the Zcash Code of Conduct 4 (except in the case of an update removing that Owner);
- it is not authorized by the stated ZIP Owners;
- it removes an Owner without their consent (unless the reason for removal is directly related to a breach of the Code of Conduct by that Owner).
The ZIP Editors MUST NOT unreasonably deny publication of a ZIP proposal or update that does not violate any of these criteria. If they refuse a proposal or update, they MUST give an explanation of which of the criteria were violated, with the exception that spam may be deleted without an explanation.
Note that it is not the primary responsibility of the ZIP Editors to review proposals for security, correctness, or implementability.
-Please send all ZIP-related communications either by email to <zips@z.cash>, or by opening an issue on the ZIPs issue tracker. All communications should abide by the Zcash Code of Conduct 4 and follow the GNU Kind Communication Guidelines
+Please send all ZIP-related communications either by email to <zips@z.cash>, or by opening an issue on the ZIPs issue tracker. All communications should abide by the Zcash Code of Conduct 4 and follow the GNU Kind Communication Guidelines
ZIP format and structure
- ZIPs SHOULD be written in reStructuredText 5, Markdown 6, or LaTeX 7. For ZIPs written in LaTeX, a Makefile MUST be provided to build (at least) a PDF version of the document.
ZIPs SHOULD be written in reStructuredText 5, Markdown 6, or LaTeX 7. For ZIPs written in LaTeX, a Makefile MUST be provided to build (at least) a PDF version of the document.
Each ZIP SHOULD have the following parts:
- Preamble — Headers containing metadata about the ZIP (see below). The License field of the preamble indicates the licensing terms, which MUST be acceptable according to the ZIP licensing requirements. @@ -112,7 +112,7 @@ License: BSD-2-Clause
- Motivation — The motivation is critical for ZIPs that want to change the Zcash protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the ZIP solves.
- Specification — The technical specification should describe the interface and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Zcash platforms.
- Rationale — The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. -
- Security and privacy considerations — If applicable, security and privacy considerations should be explicitly described, particularly if the ZIP makes explicit trade-offs or assumptions. For guidance on this section consider RFC 3552 2 as a starting point. +
- Security and privacy considerations — If applicable, security and privacy considerations should be explicitly described, particularly if the ZIP makes explicit trade-offs or assumptions. For guidance on this section consider RFC 3552 2 as a starting point.
- Reference implementation — Literal code implementing the ZIP's specification, and/or a link to the reference implementation of the ZIP's specification. The reference implementation MUST be completed before any ZIP is given status “Implemented” or “Final”, but it generally need not be completed before the ZIP is accepted into “Proposed”.
ZIP header preamble
diff --git a/zip-0032.html b/zip-0032.html
index 8bb4bbed..d6394a89 100644
--- a/zip-0032.html
+++ b/zip-0032.html
@@ -25,34 +25,34 @@ License: MIT
\(% This ZIP makes heavy use of mathematical markup. If you can see this, you may want to instead view the rendered version at https://zips.z.cash/zip-0032 .\)
Terminology
- The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-"Jubjub" refers to the elliptic curve defined in 15.
+The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+"Jubjub" refers to the elliptic curve defined in 15.
A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.
-The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 10.
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 10.
Abstract
- This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 2, to support Zcash's shielded addresses.
+This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 2, to support Zcash's shielded addresses.
The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed, for the following shielded pools (which have different internal key structures):
- Sapling
- Orchard
Previous versions of this document also defined a similar derivation system for the Sprout shielded pool. This has been removed since it was never used, and is unlikely to be used given that zcashd no longer generates Sprout addresses (and neither Zebra nor the mobile SDKs have ever done so).
-The last part shows how to use these trees in the context of existing BIP 44 5 wallets.
+The last part shows how to use these trees in the context of existing BIP 44 5 wallets.
This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses notwithstanding).
Motivation
- BIP 32 2 is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses 6) generate keys and addresses deterministically. This has several advantages over random generation:
+BIP 32 2 is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses 6) generate keys and addresses deterministically. This has several advantages over random generation:
- Wallets only need to store a single seed (particularly useful for hardware wallets). -
- A one-time backup of the seed (usually stored as a word phrase 3) can be used to recover funds from all future addresses. +
- A one-time backup of the seed (usually stored as a word phrase 3) can be used to recover funds from all future addresses.
- Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.
- Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.
At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.
Conventions
- Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification 9. They are reproduced here for convenience:
+Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification 9. They are reproduced here for convenience:
- \(\mathsf{truncate}_k(S)\) @@ -104,7 +104,7 @@ License: MIT \(\mathsf{repr}_\mathbb{J}(P)\) is the representation of the Jubjub elliptic curve point \(P\) - as a bit sequence, defined in 15. + as a bit sequence, defined in 15.
- \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(p, x)\) refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string @@ -144,9 +144,9 @@ License: MIT \(d\) to a base point on the Jubjub elliptic curve, or to \(\bot\) - if the diversifier is invalid. It is instantiated in 13. + if the diversifier is invalid. It is instantiated in 13.
The following algorithm standardized in 22 is used:
+The following algorithm standardized in 22 is used:
- \(\mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(key, tweak, x)\) @@ -181,11 +181,11 @@ License: MIT .
Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.
-We adapt the path notation of BIP 32 2 to describe shielded HD paths, using prime marks ( +
We adapt the path notation of BIP 32 2 to describe shielded HD paths, using prime marks ( \('\) ) to indicate hardened derivation ( \(i' = i + 2^{31}\) - ) as in BIP 44 5:
+ ) as in BIP 44 5:Deriving a child extended full viewing key
Let \(\mathcal{G}^\mathsf{Sapling}\) - be as defined in 14 and let + be as defined in 14 and let \(\mathcal{H}^\mathsf{Sapling}\) - be as defined in 11.
+ be as defined in 11.\(\mathsf{CDKfvk}((\mathsf{ak}_{par}, \mathsf{nk}_{par}, \mathsf{ovk}_{par}, \mathsf{dk}_{par}, \mathsf{c}_{par}), i)\) \(\rightarrow (\mathsf{ak}_{i}, \mathsf{nk}_{i}, \mathsf{ovk}_{i}, \mathsf{dk}_{i}, \mathsf{c}_{i})\) @@ -444,13 +444,13 @@ License: MIT \(\mathsf{ak}_i\) is the zero point of Jubjub, or if the corresponding \(\mathsf{ivk}\) - derived as specified in 11 is + derived as specified in 11 is \(0\) .
Sapling internal key derivation
- The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree 5, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.
+The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree 5, for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.
Deriving a Sapling internal spending key
Let \((\mathsf{ask}, \mathsf{nsk}, \mathsf{ovk}, \mathsf{dk})\) @@ -460,7 +460,7 @@ License: MIT \(\mathsf{ak}\) and \(\mathsf{nk}\) - as specified in 11. + as specified in 11.
Deriving a Sapling internal full viewing key
Let \(\mathcal{H}^\mathsf{Sapling}\) - be as defined in 11.
+ be as defined in 11.Let \((\mathsf{ak}, \mathsf{nk}, \mathsf{ovk}, \mathsf{dk})\) be the external full viewing key.
@@ -534,16 +534,16 @@ License: MIT \(R\) are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:
+
(For simplicity, the proof authorizing key is not shown.)
-This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 8.
+This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 8.
Note that the internal extended key is invalid if \(\mathsf{ak}\) is the zero point of Jubjub, or if the corresponding \(\mathsf{ivk_{internal}}\) - derived from the internal full viewing key as specified in 11 is + derived from the internal full viewing key as specified in 11 is \(0\) .
Note that the resulting child spending key may produce an invalid external FVK, as specified in 12, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.
+Note that the resulting child spending key may produce an invalid external FVK, as specified in 12, with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.
Orchard internal key derivation
As in the case of Sapling, for a given external address, we want to produce another address for use by wallets for internal operations such as change and auto-shielding. That is, for any external full viewing key we need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.
@@ -663,7 +663,7 @@ License: MIT \(\mathsf{ask}\) be the spend authorizing key if available, and let \((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\) - be the corresponding external full viewing key, obtained as specified in 12. + be the corresponding external full viewing key, obtained as specified in 12.Define \(\mathsf{DeriveInternalFVK^{Orchard}}(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\) as follows:
@@ -691,13 +691,13 @@ License: MIT \(\mathsf{ivk_{internal}}\) and \(\mathsf{ovk_{internal}}\) - fields being derived, as specified in 12 and shown in the following diagram: + fields being derived, as specified in 12 and shown in the following diagram:
+
This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 8.
-Note that the resulting FVK may be invalid, as specified in 12.
+This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 8.
+Note that the resulting FVK may be invalid, as specified in 12.
Orchard diversifier derivation
As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.
@@ -738,7 +738,7 @@ License: MITSpecification: Wallet usage
- Existing Zcash-supporting HD wallets all use BIP 44 5 to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.
+Existing Zcash-supporting HD wallets all use BIP 44 5 to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.
Key path levels
Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:
-
@@ -751,7 +751,7 @@ License: MIT
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.
- \(coin\_type\) - : a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 6. Note that in keeping with that document, all cryptocurrency testnets share + : a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 6. Note that in keeping with that document, all cryptocurrency testnets share \(coin\_type\) index \(1\) @@ -760,7 +760,7 @@ License: MIT \(account\) : numbered from index \(0\) - in sequentially increasing manner. Defined as in BIP 44 5. + in sequentially increasing manner. Defined as in BIP 44 5.
Unlike BIP 44, none of the shielded key paths have a \(change\) @@ -782,7 +782,7 @@ License: MIT payment addresses, because each diversifier has around a 50% chance of being invalid.
If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened \(address\_index\) - path level as in 5:
+ path level as in 5:-
\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)
@@ -814,7 +814,7 @@ License: MIT
Sapling Full Viewing Key Fingerprints and Tags
A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding \(\mathit{FVK}\) - (as specified in 18) is given by:
+ (as specified in 18) is given by:-
\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)
@@ -826,7 +826,7 @@ License: MIT
Orchard Full Viewing Key Fingerprints and Tags
An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding \(\mathit{FVK}\) - (as specified in 20) is given by:
+ (as specified in 20) is given by:- \(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\) @@ -851,7 +851,7 @@ License: MIT
Specification: Key Encodings
-The following encodings are analogous to the
+xprvandxpubencodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 7 encoding.The following encodings are analogous to the
xprvandxpubencodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 7 encoding.Sapling extended spending keys
A Sapling extended spending key \((\mathsf{ask, nsk, ovk, dk, c})\) @@ -943,7 +943,7 @@ License: MIT \(0\) .
When encoded as Bech32, the Human-Readable Part is
-secret-orchard-extsk-mainfor Mainnet, orsecret-orchard-extsk-testfor Testnet.We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users 21.
+We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users 21.
Values reserved due to previous specification for Sprout
diff --git a/zip-0143.html b/zip-0143.html index a9bf94af..3c18f73d 100644 --- a/zip-0143.html +++ b/zip-0143.html @@ -18,19 +18,19 @@ Category: Consensus Created: 2017-12-27 License: MITTerminology
-The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. 1
-The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. 10
-The term "Overwinter" in this document is to be interpreted as described in ZIP 201. 11
+The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. 1
+The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. 10
+The term "Overwinter" in this document is to be interpreted as described in ZIP 201. 11
Abstract
This proposal defines a new transaction digest algorithm for signature validation from the Overwinter network upgrade, in order to minimize redundant data hashing in validation, and to cover the input value by the signature.
Motivation
-There are 4 ECDSA signature validation operations in the original Zcash script system:
+CHECKSIG,CHECKSIGVERIFY,CHECKMULTISIG,CHECKMULTISIGVERIFY("sigops"). According to the sighash type (ALL,NONE, orSINGLE, possibly modified byANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. 3 The transaction digest is additionally used for the JoinSplit signature (solely with sighash typeALL). 2There are 4 ECDSA signature validation operations in the original Zcash script system:
CHECKSIG,CHECKSIGVERIFY,CHECKMULTISIG,CHECKMULTISIGVERIFY("sigops"). According to the sighash type (ALL,NONE, orSINGLE, possibly modified byANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is validated against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. 3 The transaction digest is additionally used for the JoinSplit signature (solely with sighash typeALL). 2Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:
-
-
- For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n2) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). 4 -
- The algorithm does not involve the value being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the lack of knowledge of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of a lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funds would be lost. 5 +
- For the validation of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n2) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to validate with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to validate. This could be fixed by optimizing the digest algorithm by introducing some reusable "midstate", so the time complexity becomes O(n). 4 +
- The algorithm does not involve the value being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the lack of knowledge of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of a lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funds would be lost. 5
Deploying the aforementioned fixes in the original script system is not a simple task.
The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, 6 with replay protection inspired by BUIP-HF v1.2. 7
-The new algorithm MUST be used for signatures created over the Overwinter transaction format. 12 Combined with the new consensus rule that v1 and v2 transaction formats will be invalid from the Overwinter upgrade, 12 this effectively means that all transaction signatures from the Overwinter activation height will use the new algorithm. 11
-The BLAKE2b-256 personalization field 8 is set to:
+The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, 6 with replay protection inspired by BUIP-HF v1.2. 7
+The new algorithm MUST be used for signatures created over the Overwinter transaction format. 12 Combined with the new consensus rule that v1 and v2 transaction formats will be invalid from the Overwinter upgrade, 12 this effectively means that all transaction signatures from the Overwinter activation height will use the new algorithm. 11
+The BLAKE2b-256 personalization field 8 is set to:
"ZcashSigHash" || CONSENSUS_BRANCH_ID
-
+CONSENSUS_BRANCH_IDis the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. 10 Domain separation of the signature hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will have invalid signatures on other consensus branches.CONSENSUS_BRANCH_IDis the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. 10 Domain separation of the signature hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will have invalid signatures on other consensus branches.Transaction creators MUST specify the epoch they want their transaction to be mined in. Across a network upgrade, this means that if a transaction is not mined before the activation height, it will never be mined.
Semantics of the original sighash types remain unchanged, except the following:
-
@@ -65,12 +65,12 @@ License: MIT
SINGLEdoes not commit to the input index. WhenANYONECANPAYis not set, the semantics are unchanged sincehashPrevoutsandoutpointtogether implictly commit to the input index. WhenSINGLEis used withANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.
Field definitions
-The items 7, 9, 10a, 10d have the same meaning as the original algorithm from Bitcoin. 3
+The items 7, 9, 10a, 10d have the same meaning as the original algorithm from Bitcoin. 3
1:
-headerDeserialized into two transaction properties:
+fOverwinteredandnVersion. For transactions that use this transaction digest algorithm,fOverwinteredis always set. 12Deserialized into two transaction properties:
fOverwinteredandnVersion. For transactions that use this transaction digest algorithm,fOverwinteredis always set. 122:
-nVersionGroupIdProvides domain separation of
+nVersion. It is only defined iffOverwinteredis set, which means that it is always defined for transactions that use this algorithm. 12Provides domain separation of
nVersion. It is only defined iffOverwinteredis set, which means that it is always defined for transactions that use this algorithm. 123:
hashPrevouts-
@@ -101,7 +101,7 @@ License: MIT
- The BLAKE2b-256 personalization field is set to
ZcashOutputsHashin both cases above.
- -
\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)
@@ -826,7 +826,7 @@ License: MIT
- Otherwise,
hashOutputsis auint256of0x0000......0000. 9
+ - Otherwise,
hashOutputsis auint256of0x0000......0000. 9
Note: the encoding of the sighash type is masked with 0x1F when checking whether or not the SINGLE and NONE flags are set.
8: nExpiryHeight
- The block height after which the transaction becomes unilaterally invalid, and can never be mined. 13
+The block height after which the transaction becomes unilaterally invalid, and can never be mined. 13
10b: scriptCode
The script being currently executed: redeemScript for P2SH, or scriptPubKey in the general case. This is the same script as serialized in the Sprout transaction digest algorithm.
Notes
The hashPrevouts, hashSequence, hashOutputs, and hashJoinSplits calculated in an earlier validation can be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n2) to O(n).
Refer to the reference implementation, reproduced below, for the precise algorithm:
-const unsigned char ZCASH_PREVOUTS_HASH_PERSONALIZATION[16] = - {'Z','c','a','s','h','P','r','e','v','o','u','t','H','a','s','h'}; -const unsigned char ZCASH_SEQUENCE_HASH_PERSONALIZATION[16] = - {'Z','c','a','s','h','S','e','q','u','e','n','c','H','a','s','h'}; -const unsigned char ZCASH_OUTPUTS_HASH_PERSONALIZATION[16] = - {'Z','c','a','s','h','O','u','t','p','u','t','s','H','a','s','h'}; -const unsigned char ZCASH_JOINSPLITS_HASH_PERSONALIZATION[16] = - {'Z','c','a','s','h','J','S','p','l','i','t','s','H','a','s','h'}; +const unsigned char ZCASH_PREVOUTS_HASH_PERSONALIZATION[16] = + {'Z','c','a','s','h','P','r','e','v','o','u','t','H','a','s','h'}; +const unsigned char ZCASH_SEQUENCE_HASH_PERSONALIZATION[16] = + {'Z','c','a','s','h','S','e','q','u','e','n','c','H','a','s','h'}; +const unsigned char ZCASH_OUTPUTS_HASH_PERSONALIZATION[16] = + {'Z','c','a','s','h','O','u','t','p','u','t','s','H','a','s','h'}; +const unsigned char ZCASH_JOINSPLITS_HASH_PERSONALIZATION[16] = + {'Z','c','a','s','h','J','S','p','l','i','t','s','H','a','s','h'}; // The default values are zeroes -uint256 hashPrevouts; -uint256 hashSequence; -uint256 hashOutputs; -uint256 hashJoinSplits; +uint256 hashPrevouts; +uint256 hashSequence; +uint256 hashOutputs; +uint256 hashJoinSplits; -if (!(nHashType & SIGHASH_ANYONECANPAY)) { - CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_PREVOUTS_HASH_PERSONALIZATION); - for (unsigned int n = 0; n < txTo.vin.size(); n++) { - ss << txTo.vin[n].prevout; - } - hashPrevouts = ss.GetHash(); -} +if (!(nHashType & SIGHASH_ANYONECANPAY)) { + CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_PREVOUTS_HASH_PERSONALIZATION); + for (unsigned int n = 0; n < txTo.vin.size(); n++) { + ss << txTo.vin[n].prevout; + } + hashPrevouts = ss.GetHash(); +} -if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { - CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_SEQUENCE_HASH_PERSONALIZATION); - for (unsigned int n = 0; n < txTo.vin.size(); n++) { - ss << txTo.vin[n].nSequence; - } - hashSequence = ss.GetHash(); -} +if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { + CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_SEQUENCE_HASH_PERSONALIZATION); + for (unsigned int n = 0; n < txTo.vin.size(); n++) { + ss << txTo.vin[n].nSequence; + } + hashSequence = ss.GetHash(); +} -if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { - CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_OUTPUTS_HASH_PERSONALIZATION); - for (unsigned int n = 0; n < txTo.vout.size(); n++) { - ss << txTo.vout[n]; - } - hashOutputs = ss.GetHash(); -} else if ((nHashType & 0x1f) == SIGHASH_SINGLE && nIn < txTo.vout.size()) { - CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_OUTPUTS_HASH_PERSONALIZATION); - ss << txTo.vout[nIn]; - hashOutputs = ss.GetHash(); -} +if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { + CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_OUTPUTS_HASH_PERSONALIZATION); + for (unsigned int n = 0; n < txTo.vout.size(); n++) { + ss << txTo.vout[n]; + } + hashOutputs = ss.GetHash(); +} else if ((nHashType & 0x1f) == SIGHASH_SINGLE && nIn < txTo.vout.size()) { + CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_OUTPUTS_HASH_PERSONALIZATION); + ss << txTo.vout[nIn]; + hashOutputs = ss.GetHash(); +} -if (!txTo.vjoinsplit.empty()) { - CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_JOINSPLITS_HASH_PERSONALIZATION); - for (unsigned int n = 0; n < txTo.vjoinsplit.size(); n++) { - ss << txTo.vjoinsplit[n]; - } - ss << txTo.joinSplitPubKey; - hashJoinSplits = ss.GetHash(); -} +if (!txTo.vjoinsplit.empty()) { + CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_JOINSPLITS_HASH_PERSONALIZATION); + for (unsigned int n = 0; n < txTo.vjoinsplit.size(); n++) { + ss << txTo.vjoinsplit[n]; + } + ss << txTo.joinSplitPubKey; + hashJoinSplits = ss.GetHash(); +} -uint32_t leConsensusBranchId = htole32(consensusBranchId); -unsigned char personalization[16] = {}; -memcpy(personalization, "ZcashSigHash", 12); -memcpy(personalization+12, &leConsensusBranchId, 4); +uint32_t leConsensusBranchId = htole32(consensusBranchId); +unsigned char personalization[16] = {}; +memcpy(personalization, "ZcashSigHash", 12); +memcpy(personalization+12, &leConsensusBranchId, 4); -CBLAKE2bWriter ss(SER_GETHASH, 0, personalization); +CBLAKE2bWriter ss(SER_GETHASH, 0, personalization); // fOverwintered and nVersion -ss << txTo.GetHeader(); +ss << txTo.GetHeader(); // Version group ID -ss << txTo.nVersionGroupId; +ss << txTo.nVersionGroupId; // Input prevouts/nSequence (none/all, depending on flags) -ss << hashPrevouts; -ss << hashSequence; +ss << hashPrevouts; +ss << hashSequence; // Outputs (none/one/all, depending on flags) -ss << hashOutputs; +ss << hashOutputs; // JoinSplits -ss << hashJoinSplits; +ss << hashJoinSplits; // Locktime -ss << txTo.nLockTime; +ss << txTo.nLockTime; // Expiry height -ss << txTo.nExpiryHeight; +ss << txTo.nExpiryHeight; // Sighash type -ss << nHashType; +ss << nHashType; -if (nIn != NOT_AN_INPUT) { - // The input being signed (replacing the scriptSig with scriptCode + amount) - // The prevout may already be contained in hashPrevout, and the nSequence - // may already be contained in hashSequence. - ss << txTo.vin[nIn].prevout; - ss << static_cast<const CScriptBase&>(scriptCode); - ss << amount; - ss << txTo.vin[nIn].nSequence; -} +if (nIn != NOT_AN_INPUT) { + // The input being signed (replacing the scriptSig with scriptCode + amount) + // The prevout may already be contained in hashPrevout, and the nSequence + // may already be contained in hashSequence. + ss << txTo.vin[nIn].prevout; + ss << static_cast<const CScriptBase&>(scriptCode); + ss << amount; + ss << txTo.vin[nIn].nSequence; +} -return ss.GetHash();+return ss.GetHash();
Example
- To ensure consistency in consensus-critical behaviour, developers should test their implementations against the ZIP 143 test vectors 14. The first two test vectors are broken out below for clarity. Note that 32-byte values below are exactly as the hash function returns, and are not reversed. Further examples can be found in the SignatureHash test data 15.
-The test vectors below should be verified with the Overwinter consensus branch ID (0x5ba81b19) 11.
+To ensure consistency in consensus-critical behaviour, developers should test their implementations against the ZIP 143 test vectors 14. The first two test vectors are broken out below for clarity. Note that 32-byte values below are exactly as the hash function returns, and are not reversed. Further examples can be found in the SignatureHash test data 15.
+The test vectors below should be verified with the Overwinter consensus branch ID (0x5ba81b19) 11.
Test vector 1
Raw transaction:
030000807082c4030002e7719811893e0000095200ac6551ac636565b2835a0805750200025151481cdd86b3cc431800 @@ -339,7 +339,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7
Deployment
- This proposal is deployed with the Overwinter network upgrade. 11
+This proposal is deployed with the Overwinter network upgrade. 11
Backward compatibility
This proposal is backwards-compatible with old UTXOs. It is not backwards-compatible with older software. All transactions will be required to use this transaction digest algorithm for signatures, and so transactions created by older software will be rejected by the network.
diff --git a/zip-0155.html b/zip-0155.html index 073b73f8..2157b5df 100644 --- a/zip-0155.html +++ b/zip-0155.html @@ -18,9 +18,9 @@ License: BSD-2-Clause Discussions-To: <https://github.com/zcash/zips/issues/542> Pull-Request: <https://github.com/zcash/zips/pull/543>Terminology
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 4
-The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 2.
+The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 4
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 2.
"P2P network" means the Zcash peer-to-peer network.
uint8, uint16, and uint32 denote unsigned integer data types of the corresponding length (8, 16, or 32 bits respectively).
This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current addr message.
Motivation
- Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy 9. These services have 256-bit addresses and thus do not fit in the existing addr message (unchanged from Bitcoin 7), which encapsulates onion addresses in OnionCat IPv6 addresses.
Tor v3 onion services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old v2 onion services, among which better encryption and privacy 9. These services have 256-bit addresses and thus do not fit in the existing addr message (unchanged from Bitcoin 7), which encapsulates onion addresses in OnionCat IPv6 addresses.
Other transport-layer protocols such as I2P have always used longer addresses. This change would make it possible to gossip such addresses over the P2P network, so that other peers can connect to them.
Specification
- The addrv2 message is defined as a message where the command field is (NUL-padded) "addrv2". It is serialized in the standard encoding for P2P messages. Its format is similar to the current addr message format described in 7, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to 8.
The addrv2 message is defined as a message where the command field is (NUL-padded) "addrv2". It is serialized in the standard encoding for P2P messages. Its format is similar to the current addr message format described in 7, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to 8.
This means that the message contains a serialized vector of the following structure:
-@@ -127,14 +127,14 @@ Pull-Request: <https://githu
Network ID 0x03 is intentionally not assigned. In BIP 155 3 it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
Network ID 0x03 is intentionally not assigned. In BIP 155 3 it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
Clients SHOULD gossip valid, potentially routable addresses from all known networks, even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to.
Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.
Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.
Network address encodings
The IPV4 and IPV6 network IDs use addresses encoded in the usual way for binary IPv4 and IPv6 addresses in network byte order (big endian).
Tor v3 address encoding
- According to the spec 9, version 3 .onion addresses are encoded as follows:
According to the spec 9, version 3 .onion addresses are encoded as follows:
onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion"
CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes
where:
@@ -143,30 +143,30 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytesVERSION is a one-byte version field (default value 0x03);".onion" and ".onion checksum" are constant strings;CHECKSUM is truncated to two bytes before inserting it in onion_address;H() is the SHA3-256 cryptographic hash function. 10H() is the SHA3-256 cryptographic hash function. 10Tor v3 addresses MUST be sent with the TORV3 network ID, with the 32-byte PUBKEY part in the addr field. As VERSION will always be 0x03 in the case of v3 addresses, this is enough to reconstruct the onion address.
I2P address encoding
- Like Tor, I2P naming uses a base32-encoded address format 11.
+Like Tor, I2P naming uses a base32-encoded address format 11.
I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by .b32.i2p. The base32 encoding does not include "=" padding characters.
I2P addresses MUST be sent with the I2P network ID, with the decoded SHA-256 hash as address field.
Cjdns address encoding
- Cjdns addresses are simply IPv6 addresses in the fc00::/8 range 12. They MUST be sent with the CJDNS network ID. They are encoded in network byte order (big endian) as for the IPV6 network ID.
Cjdns addresses are simply IPv6 addresses in the fc00::/8 range 12. They MUST be sent with the CJDNS network ID. They are encoded in network byte order (big endian) as for the IPV6 network ID.
Deployment
TODO: change ${PLACEHOLDER} to a specific peer protocol version.
-Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet 6.
+Support for this specification is signalled by peer protocol version ${PLACEHOLDER} (on both Testnet and Mainnet). Note that this is the same peer protocol version that signals support for NU5 on Mainnet 6.
Nodes that have not negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MUST NOT send addrv2 messages on that connection.
A node that has negotiated peer protocol version ${PLACEHOLDER} or higher on a given connection, MAY still send addr messages on the connection, and MUST handle received addr messages as it would have done prior to this ZIP.
Rationale
- This ZIP is closely based on BIP 155 3, with the following changes:
+This ZIP is closely based on BIP 155 3, with the following changes:
-
-
- Deployment: support for the
addrv2message is signalled by advertising a peer protocol version of ${PLACEHOLDER} or higher, not by sending asendaddrv2message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example theMSG_WTXinv type defined in ZIP 239 5, have taken the same approach to signalling.
+ - Deployment: support for the
addrv2message is signalled by advertising a peer protocol version of ${PLACEHOLDER} or higher, not by sending asendaddrv2message. This is motivated by a desire to avoid an exponential explosion in the space of possible feature configurations in a given peer-to-peer connection. In Zcash, unlike Bitcoin, the space of such configurations is effectively constant no matter how many peer-to-peer protocol changes are made, because nodes that do not support a given peer protocol version will drop off the network over time if they do not support the latest Network Upgrade. The feature configuration for a given connection is also established at version negotiation, and cannot change after that point without reconnecting. Other peer-to-peer protocol changes ported from the Bitcoin peer-to-peer protocol, for example theMSG_WTXinv type defined in ZIP 239 5, have taken the same approach to signalling. - No Network ID for Tor v2 onion addresses: the Tor network is expected to have removed support for these addresses in the timeframe for deployment of this ZIP.
- Clients MUST, rather than SHOULD, reject
addrv2messages with more than 1,000 addresses. Making this a consistent requirement promotes interoperability. - Clients MUST NOT, rather than SHOULD NOT, gossip addresses from unknown networks. @@ -177,7 +177,7 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes
TBD.
Acknowledgements
- This ZIP is closely based on BIP 155 3, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.
+This ZIP is closely based on BIP 155 3, written by Wladimir J. van der Laan. Zancas Wilcox ported the implementation for Zcashd.
Acknowledgements for BIP 155:
- Jonas Schnelli: change
servicesfield toCompactSize, to make the message more compact in the likely case instead of always using 8 bytes.
diff --git a/zip-0173.html b/zip-0173.html
index 520b4c6e..04d86673 100644
--- a/zip-0173.html
+++ b/zip-0173.html
@@ -18,15 +18,15 @@ Category: Standards / Wallet
Created: 2018-06-13
License: MIT
- Base58 needs a lot of space in QR codes, as it cannot use the ''alphanumeric mode''.
- The mixed case in Base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud. @@ -34,11 +34,11 @@ License: MIT
- Most of the research on error-detecting codes only applies to character-set sizes that are a prime power, which 58 is not.
- Base58 decoding is complicated and relatively slow.
- The human-readable part, which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications. @@ -158,7 +158,7 @@ def bech32_verify_checksum(hrp, data):
- The resulting groups are interpreted as the raw encoding of the appropriate address or key type, with the most significant bit first in each byte.
Terminology
- The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. 1
-The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 4
-The term "Sapling" in this document is to be interpreted as described in ZIP 205. 5
+The key words "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119. 1
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 4
+The term "Sapling" in this document is to be interpreted as described in ZIP 205. 5
Abstract
This document proposes a checksummed base32 format, "Bech32", and a standard for Sapling addresses and keys using it.
Motivation
- Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256 checksum, inherited from Bitcoin. They were part of the original Bitcoin software and their scope was extended in BIP 13 6 for P2SH (Pay-to-Script-Hash) addresses. However, both the character set and the checksum algorithm have limitations:
+Since launch, Zcash has relied on Base58 addresses with a truncated double-SHA256 checksum, inherited from Bitcoin. They were part of the original Bitcoin software and their scope was extended in BIP 13 6 for P2SH (Pay-to-Script-Hash) addresses. However, both the character set and the checksum algorithm have limitations:
To address these issues, Bitcoin adopted a new encoding called Bech32 7, for use with address types added by its Segregated Witness proposal. Zcash does not implement Segregated Witness, but it reuses Bech32 with address and key types introduced by the Sapling network upgrade 5.
-Since the description of Bech32 in 7 is partially entangled with Segregated Witness address formats, we have found it clearer to write this ZIP to specify Bech32 separately. This specification should be read in conjunction with section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol specification 2, and with ZIP 32 which specifies additional key types for support of shielded hierarchical deterministic wallets 3.
+To address these issues, Bitcoin adopted a new encoding called Bech32 7, for use with address types added by its Segregated Witness proposal. Zcash does not implement Segregated Witness, but it reuses Bech32 with address and key types introduced by the Sapling network upgrade 5.
+Since the description of Bech32 in 7 is partially entangled with Segregated Witness address formats, we have found it clearer to write this ZIP to specify Bech32 separately. This specification should be read in conjunction with section 5.6 ("Encodings of Addresses and Keys") of the Zcash Sapling protocol specification 2, and with ZIP 32 which specifies additional key types for support of shielded hierarchical deterministic wallets 3.
Specification
- We describe the general checksummed base32 format called ''Bech32''. Its use for Sapling payment addresses and keys is defined in the Sapling protocol specification 2.
+We describe the general checksummed base32 format called ''Bech32''. Its use for Sapling payment addresses and keys is defined in the Sapling protocol specification 2.
A Bech32 string consists of:
Decoders SHOULD enforce known-length restrictions on address and key types.
-For example, 2 specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.
+For example, 2 specifies that the length of the raw encoding of a Sapling payment address is 43 bytes (88 + 256 bits). This results in a Bech32-encoded Sapling payment address being 78 characters long.
Existing character sets for base-32 encodings include RFC 3548 and z-base-32. The set used for Bech32 was chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.
Why are the high bits of the human-readable part processed first?
- This design choice had a rationale for Bitcoin Segregated Witness addresses (see 7) that does not apply to Zcash Sapling addresses. It is retained for compatibility with Bech32 encoders/decoders written for Bitcoin.
+This design choice had a rationale for Bitcoin Segregated Witness addresses (see 7) that does not apply to Zcash Sapling addresses. It is retained for compatibility with Bech32 encoders/decoders written for Bitcoin.
Reference implementations
diff --git a/zip-0200.html b/zip-0200.html
index 3110d361..6f4414ba 100644
--- a/zip-0200.html
+++ b/zip-0200.html
@@ -14,7 +14,7 @@ Category: Consensus
Created: 2018-01-08
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 key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
The terms below are to be interpreted as follows:
- Block chain @@ -33,8 +33,8 @@ License: MIT
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 any users opting out of the changes.
Motivation
- Zcash is a consensual currency: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. 2 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 End-of-Service halt feature, causing nodes running a particular version 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: 3
Zcash is a consensual currency: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. 2 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 End-of-Service halt feature, causing nodes running a particular version 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: 3
- 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:
@@ -70,19 +70,19 @@ License: MIT
Activation mechanism
The Zcash block chain is broken into "epochs" of block height intervals
[ACTIVATION_HEIGHT_N, ACTIVATION_HEIGHT_{N+1})(i.e. includingACTIVATION_HEIGHT_Nand excludingACTIVATION_HEIGHT_{N+1}), on which consensus rule sets are defined.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:
-if (CurrentEpoch(chainActive.Height(), Params().GetConsensus()) == Consensus::UPGRADE_OVERWINTER) { - // Overwinter-specific logic -} else { - // Non-Overwinter logic -} +
if (CurrentEpoch(chainActive.Height(), Params().GetConsensus()) == Consensus::UPGRADE_OVERWINTER) { + // Overwinter-specific logic +} else { + // Non-Overwinter logic +} // ... -if (NetworkUpgradeActive(pindex->nHeight, Params().GetConsensus(), Consensus::UPGRADE_OVERWINTER)) { - // Overwinter consensus rules applied to block -} else { - // Pre-Overwinter consensus rules applied to block -}
+if (NetworkUpgradeActive(pindex->nHeight, Params().GetConsensus(), Consensus::UPGRADE_OVERWINTER)) { + // Overwinter consensus rules applied to block +} else { + // Pre-Overwinter consensus rules applied to block +}Block validation
Incoming blocks known to have a particular height (due to their parent chain being entirely known) MUST be validated under the consensus rules corresponding to the expected consensus 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, so that they can be reconsidered in the future after all their parents have been received.
@@ -99,8 +99,8 @@ License: MITWhen the current chain tip height reaches
ACTIVATION_HEIGHT, the node's local transaction memory pool SHOULD be cleared of transactions that will never be valid on the post-upgrade consensus branch.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. 6 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 consensus branch.
-After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific
+CONSENSUS_BRANCH_ID. 4Before 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. 6 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 consensus branch.
+After the Overwinter network upgrade, two-way replay protection is ensured by transaction signatures committing to a specific
CONSENSUS_BRANCH_ID. 4Wipe-out protection
Nodes running upgrade-aware software versions will enforce the upgraded consensus rules from
@@ -108,7 +108,7 @@ License: MITACTIVATION_HEIGHT. The chain from that height will not reorganize to a pre-upgrade consensus branch if any block in that consensus branch would violate the new consensus rules.Deployment
-This proposal will be deployed with the Overwinter network upgrade. 5
+This proposal will be deployed with the Overwinter network upgrade. 5
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.
diff --git a/zip-0201.html b/zip-0201.html index 7b0a3413..83b92e5e 100644 --- a/zip-0201.html +++ b/zip-0201.html @@ -15,8 +15,8 @@ Category: Network Created: 2018-01-15 License: MITTerminology
-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 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 below are to be interpreted as follows:
- Overwinter @@ -24,12 +24,12 @@ License: MIT
Abstract
-This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Mechanism 3.
+This proposal defines an upgrade to the network handshake and peer management required for network upgrades following the Network Upgrade Mechanism 3.
Related to:
Motivation
@@ -37,7 +37,7 @@ License: MITSpecification
When a new inbound connection is received or an outbound connection created, a CNode object is instantiated with the version field set to INIT_PROTO_VERSION which has a value of 209. This value is not transmitted across the network, but for legacy reasons and technical debt beyond the scope of this ZIP, this value will not be changed.
-Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake 8 involves "version" and "verack" messages being exchanged.:
+Once the two nodes have connected and started the handshake to negotiate the protocol version, the version field of CNode will be updated. The handshake 8 involves "version" and "verack" messages being exchanged.:
L -> R: Send version message with the local peer's version R -> L: Send version message back R -> L: Send verack message @@ -70,7 +70,7 @@ static const int MIN_PEER_PROTO_VERSION = 170002;
To prepare for mainnet activation, Overwinter nodes will contain the following constants:
static const int PROTOCOL_VERSION = 170005; static const int MIN_PEER_PROTO_VERSION = 170002;
-On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the
+NODE_BLOOMservice bit defined in 6.)On mainnet, a pre-Overwinter node is defined to be a node for which the highest supported protocol version is <= 170004. (Nodes running protocol version 170003 or 170004 do not have a mainnet activation height set. The intermediate protocol version 170004 is used to indicate support for the
NODE_BLOOMservice bit defined in 6.)These constants allow pre-Overwinter nodes that support protocol versions 170002 to 170004 inclusive, and Overwinter nodes (which support protocol versions 170002 to 170005 inclusive before Overwinter activation) to remain connected until the activation.
As these constants cannot be changed at run-time, once Overwinter activates on testnet or mainnet, Overwinter nodes should take steps to:
-
@@ -80,7 +80,7 @@ static const int MIN_PEER_PROTO_VERSION = 170002;
Network Coalescence
Prior to the activation of Overwinter, nodes running a pre-Overwinter protocol version (e.g. 170002) and the Overwinter protocol version (170003 for testnet; 170005 for mainnet) remain connected with the same consensus rules, but it is desirable for nodes supporting Overwinter to connect preferentially to other nodes supporting Overwinter.
-This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. 9
+This is intended to help the network partition smoothly, since nodes should already be connected to (a majority of) peers running the same protocol version. Otherwise an Overwinter node may find their connections to Sprout nodes dropped suddenly at the activation height, potentially leaving them isolated and susceptible to eclipse attacks. 9
To assist network coalescence before the activation height, we update the eviction process to place a higher priority on evicting Sprout nodes.
Currently, an eviction process takes place when new inbound connections arrive, but the node has already connected to the maximum number of inbound peers:
if (nInbound >= nMaxInbound) @@ -158,7 +158,7 @@ if (nActivationHeight > 0 &&Deployment of Overwinter
-The Overwinter network upgrade defines the following network upgrade constants 3:
+The Overwinter network upgrade defines the following network upgrade constants 3:
- CONSENSUS_BRANCH_ID
0x5ba81b19
@@ -170,11 +170,11 @@ if (nActivationHeight > 0 &&
The following ZIPs are deployed by Overwinter:
Backward compatibility
diff --git a/zip-0202.html b/zip-0202.html index f52d15a0..02e5d1aa 100644 --- a/zip-0202.html +++ b/zip-0202.html @@ -15,12 +15,12 @@ Category: Consensus Created: 2018-01-10 License: MITTerminology
-The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. 3
-The term "Overwinter" in this document is to be interpreted as described in ZIP 201. 4
+The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+The terms "consensus branch", "network upgrade", and "consensus rule change" in this document are to be interpreted as described in ZIP 200. 3
+The term "Overwinter" in this document is to be interpreted as described in ZIP 201. 4
Abstract
-This proposal defines a new transaction format required for Network Upgrade Mechanism 3 and Transaction Expiry 5.
+This proposal defines a new transaction format required for Network Upgrade Mechanism 3 and Transaction Expiry 5.
Motivation
Zcash launched with support for upstream Bitcoin version 1 transactions and defined a new version 2 transaction format which added fields required for shielded transactions.
@@ -98,12 +98,12 @@ License: MITA new transaction format is required to:
-
-
- support safe network upgrades as specified in Network Upgrade Mechanism 3; +
- support safe network upgrades as specified in Network Upgrade Mechanism 3;
- provide replay protection between pre-Overwinter and Overwinter consensus branches during upgrades;
- provide replay protection between different consensus branches post-Overwinter;
- enable a consensus branch to support multiple transaction version formats;
- ensure transaction formats are parsed uniquely across parallel consensus branches; -
- support transaction expiry 5. +
- support transaction expiry 5.
Specification
@@ -268,7 +268,7 @@ License: MITHowever, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.
Expiry Height
-The expiry height field, as defined in the Transaction Expiry ZIP 5, stores the block height after which a transaction can no longer be mined.
+The expiry height field, as defined in the Transaction Expiry ZIP 5, stores the block height after which a transaction can no longer be mined.
Transaction Validation
A valid Overwinter transaction intended for Zcash MUST have:
@@ -283,7 +283,7 @@ License: MIT- the version group ID is unknown; or
- the version number is unknown.
Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP 2.
+Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP 2.
Implementation
@@ -317,14 +317,14 @@ License: MIT
}
It is expected that this test involving nVersionGroupId is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.
However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.
-Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP 2.
+Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP 2.
Deployment
- This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in 4.
+This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in 4.
Backwards compatibility
- This proposal intentionally creates what is known as a "bilateral consensus rule change" 3 between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.
+This proposal intentionally creates what is known as a "bilateral consensus rule change" 3 between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.
Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group IDs.
Reference Implementation
diff --git a/zip-0203.html b/zip-0203.html
index 7fa7468f..7a8add0b 100644
--- a/zip-0203.html
+++ b/zip-0203.html
@@ -48,10 +48,10 @@ License: MIT
Coinbase: nExpiryHeight on coinbase transactions is ignored, and is set to 0 by convention.
Every time a transaction expires and should be removed from the mempool, so should all of its dependent transactions.
Changes for Blossom
- On Blossom activation 2, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.
+On Blossom activation 2, the default changes to 40 blocks from the current height, which still represents about 50 minutes at the revised 75-second target block spacing.
Changes for NU5
- As mentioned above, nExpiryHeight is ignored for coinbase transactions. However, from NU5 activation 3, the nExpiryHeight field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on nExpiryHeight is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification 4.
As mentioned above, nExpiryHeight is ignored for coinbase transactions. However, from NU5 activation 3, the nExpiryHeight field of a coinbase transaction MUST be set equal to the block height. Also, for coinbase transactions only, the bound of 499999999 on nExpiryHeight is removed. The motivation is to ensure that transaction IDs remain unique, as explained in more detail in a note in Section 7.1 of the protocol specification 4.
Wallet behavior and UI
With the addition of this feature, zero-confirmation transactions with an expiration block height set will have even less guarantee of inclusion. This means that UIs and services must never rely on zero-confirmation transactions in Zcash.
@@ -69,7 +69,7 @@ License: MIT--txexpirydelta=100
Deployment
- This feature will be deployed with Overwinter. The activation blockheight proposal is in 1.
+This feature will be deployed with Overwinter. The activation blockheight proposal is in 1.
Reference Implementation
diff --git a/zip-0205.html b/zip-0205.html
index 4dfc25eb..c58571c9 100644
--- a/zip-0205.html
+++ b/zip-0205.html
@@ -15,9 +15,9 @@ Category: Consensus / Network
Created: 2018-10-08
License: MIT
Terminology
- The key words "MUST" and "SHOULD" 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. 7
-The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.
+The key words "MUST" and "SHOULD" 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. 7
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 3.
The terms below are to be interpreted as follows:
- Sapling @@ -31,12 +31,12 @@ License: MIT
- The Zcash Protocol Specification 2. -
- Transaction Signature Validation for Sapling 9. -
- Network Upgrade Mechanism 7. +
- The Zcash Protocol Specification 2. +
- Transaction Signature Validation for Sapling 9. +
- Network Upgrade Mechanism 7.
- CONSENSUS_BRANCH_ID
0x76b809bb
@@ -52,7 +52,7 @@ License: MIT
- reject new connections from pre-Sapling nodes; @@ -60,8 +60,8 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
- The Zcash Protocol Specification 2. -
- Shorter Block Target Spacing 5. -
- Network Upgrade Mechanism 3. +
- The Zcash Protocol Specification 2. +
- Shorter Block Target Spacing 5. +
- Network Upgrade Mechanism 3.
- CONSENSUS_BRANCH_ID
0x2BB40E60
@@ -54,7 +54,7 @@ License: MIT
- reject new connections from pre-Blossom nodes on that network; @@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
- Canopy
- Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.
- Testnet -
- The Zcash test network, as defined in the Zcash Protocol Specification. 4 +
- The Zcash test network, as defined in the Zcash Protocol Specification. 4
- Mainnet -
- The Zcash production network, as defined in the Zcash Protocol Specification. 4 +
- The Zcash production network, as defined in the Zcash Protocol Specification. 4
- \(\mathsf{BlossomActivationHeight}\) @@ -74,7 +74,7 @@ License: MIT
- The existing consensus rule for payment of the Founders' Reward 8 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.) +
- The existing consensus rule for payment of the Founders' Reward 8 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
- The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.
- The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form
OP_HASH160 RedeemScriptHash(height) OP_EQUALas thescriptPubKey.
- - The "prescribed way" to pay a Sapling address is as defined in 13. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be +
- The "prescribed way" to pay a Sapling address is as defined in 13. That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be \(\mathbf{0x02}\) - , as specified in 12. + , as specified in 12.
- Greater throughput of transactions in unit time.
Sapling deployment
The primary sources of information about Sapling consensus protocol changes are:
-
-
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:
+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:
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 8.
+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:
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 MUST be 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.7.4 of that specification 6.
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 MUST be 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.7.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 modified as well, and this affects difficulty adjustment for subsequent blocks.
This change does not affect Mainnet.
Terminology
- The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 3
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 3
The terms below are to be interpreted as follows:
Abstract
@@ -34,12 +34,12 @@ License: MIT
Blossom deployment
The primary sources of information about Blossom consensus protocol changes are:
-
-
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 Blossom upgrade:
+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 Blossom upgrade:
For each network (testnet and mainnet), approximately three days (defined in terms of block height) before the corresponding Blossom activation height, nodes compatible with Blossom activation on that network will change the behaviour of their peer connection logic in order to prefer pre-Blossom peers on that network 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.
+The implementation is similar to that for Overwinter which was described in 4.
Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:
Backward compatibility
Prior to the network upgrade activating on each network, Blossom and pre-Blossom nodes are compatible and can connect to each other. However, Blossom nodes will have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Blossom nodes can still accept the numerically larger protocol version used by Blossom as being valid, Blossom nodes will always disconnect peers using lower protocol versions.
-Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in 2 section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.
+Unlike Overwinter and Sapling, Blossom does not define a new transaction version. Blossom transactions are therefore in the same v4 format as Sapling transactions, and use the same version group ID, i.e. 0x892F2085 as defined in 2 section 7.1. This does not imply that transactions are valid across the Blossom activation, since signatures MUST use the appropriate consensus branch ID.
Support in zcashd
Support for Blossom on testnet is implemented in zcashd version 2.0.7, which advertises protocol version 170008. Support for Blossom on mainnet is implemented in zcashd version 2.1.0, which advertises protocol version 170009.
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 subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 3 7
-The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 10
+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 subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 3 7
+The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. 10
The terms below are to be interpreted as follows:
Abstract
This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.
-This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 14. It should be read in conjunction with ZIP 1014 16, which describes the high-level requirements for that fund.
+This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214 14. It should be read in conjunction with ZIP 1014 16, which describes the high-level requirements for that fund.
Motivation
- Motivation for the Zcash Development Fund is considered in ZIP 1014 16.
+Motivation for the Zcash Development Fund is considered in ZIP 1014 16.
This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders' Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP is being reintroduced for that purpose in order to reuse specification, analysis, and implementation effort.
Requirements
- The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 14 to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 16, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.
+The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214 14 to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014 16, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.
As for the original Founders' Reward, a mechanism is provided to allow addresses for a given funding stream to be changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.
Specification
Definitions
- We use the following constants and functions defined in 5, 6, 7, and 8:
+We use the following constants and functions defined in 5, 6, 7, and 8:
Funding streams
A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).
-By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. 11
+By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example. 11
The value of a funding stream at a given block height is defined as:
On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.
Consensus rules
- Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 8
+Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced. 8
Once the Canopy network upgrade activates:
-
-
For the funding stream definitions to be activated at Canopy, see ZIP 214. 14 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 9
+For the funding stream definitions to be activated at Canopy, see ZIP 214. 14 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 9
Deployment
- This proposal is intended to be deployed with Canopy. 15
+This proposal is intended to be deployed with Canopy. 15
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.
diff --git a/zip-0208.html b/zip-0208.html index ffb11c0a..cc0c24f7 100644 --- a/zip-0208.html +++ b/zip-0208.html @@ -17,13 +17,13 @@ Created: 2019-01-10 License: MIT Pull-Request: <https://github.com/zcash/zips/pull/237>Terminology
- The key words "MUST" and "SHOULD" 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 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.12 of the Zcash Protocol Specification 4.
+The key words "MUST" and "SHOULD" 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 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.12 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 11.
+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
@@ -33,15 +33,15 @@ Pull-Request: <https://githu
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 13 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 11.
+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) [later moved to section 7.7.3], make the following changes:
Define IsBlossomActivated(height) to return true if height ≥ BlossomActivationHeight, otherwise false.
This specification assumes that BlossomActivationHeight ≥ SlowStartInterval.
@@ -111,9 +111,9 @@ Pull-Request: <https://githuThe 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 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 greater than 6 · PoWTargetSpacing(height) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its nBits field MUST be 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.7.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 modified as well, and this affects difficulty adjustment for subsequent blocks.
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 greater than 6 · PoWTargetSpacing(height) seconds after that of the preceding block, then the block is a minimum-difficulty block. In that case its nBits field MUST be 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.7.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 modified as well, and this affects difficulty adjustment for subsequent blocks.
This change does not affect Mainnet.
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 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.
+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
@@ -137,7 +137,7 @@ Pull-Request: <https://githu
// 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.7.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.
+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.7.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
@@ -194,7 +194,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;
Deployment
- This proposal will be deployed with the Blossom network upgrade. 11
+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.
diff --git a/zip-0209.html b/zip-0209.html index abbce8b5..bca26080 100644 --- a/zip-0209.html +++ b/zip-0209.html @@ -15,12 +15,12 @@ Category: Consensus Created: 2019-02-25 License: MITTerminology
- The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
-The term "block chain" and "network upgrade" are to be interpreted as defined in 3.
+The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. 1
+The term "block chain" and "network upgrade" are to be interpreted as defined in 3.
The "Sprout chain value pool balance" for a given block chain is the sum of all vpub_old fields for transactions in the block chain, minus the sum of all vpub_new fields for transactions in the block chain.
The "Sapling chain value pool balance" for a given block chain is the negation of the sum of all valueBalanceSapling fields for transactions in the block chain.
The "Orchard chain value pool balance" for a given block chain is the negation of the sum of all valueBalanceOrchard fields for transactions in the block chain. (Before NU5 has activated, the Orchard chain value pool balance is zero.)
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 2.
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 2.
Abstract
This proposal defines how the consensus rules are altered such that blocks that produce negative shielded chain value pool balances are prohibited.
@@ -34,9 +34,9 @@ License: MITNodes MAY relay transactions even if one or more of them cannot be mined due to the aforementioned restriction.
Deployment
- This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 3 and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.
+This consensus rule is not deployed as part of a network upgrade as defined in ZIP-200 3 and there is no mechanism by which the network will synchronize to enforce this rule. Rather, all nodes SHOULD begin enforcing this consensus rule upon acceptance of this proposal.
There is a risk that before all nodes on the network begin enforcing this consensus rule that block(s) will be produced that violate it, potentially leading to network fragmentation. This is considered sufficiently unlikely that the benefits of enforcing this consensus rule sooner are overwhelming.
-This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet. The application to the Orchard chain value pool balance will be deployed from NU5 activation 4.
+This specification was deployed in zcashd v2.0.4 for Testnet, and in zcashd v2.0.5 for Mainnet. The application to the Orchard chain value pool balance will be deployed from NU5 activation 4.
+ 
+ 
+