diff --git a/zip-0032.html b/zip-0032.html index bb88c3e3..fba5d76b 100644 --- a/zip-0032.html +++ b/zip-0032.html @@ -25,7 +25,7 @@ License: MIT

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 13.

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.11 of the Zcash Protocol Specification 9.

+

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

Abstract

This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 2, to support Zcash's shielded addresses.

@@ -984,7 +984,7 @@ License: MIT 8 - Zcash Protocol Specification, Version 2020.1.24 or later [NU5 proposal] + Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] @@ -992,7 +992,7 @@ License: MIT 9 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet @@ -1000,7 +1000,7 @@ License: MIT 10 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 4.2.2: Sapling Key Components + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.2: Sapling Key Components @@ -1008,7 +1008,7 @@ License: MIT 11 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.1.6: DiversifyHash Hash Function + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions @@ -1016,7 +1016,7 @@ License: MIT 12 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature @@ -1024,7 +1024,7 @@ License: MIT 13 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.8.3: Jubjub + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub @@ -1032,7 +1032,7 @@ License: MIT 14 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.1: Sprout Shielded Payment Addresses + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.1: Sprout Payment Addresses @@ -1040,7 +1040,7 @@ License: MIT 15 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys @@ -1048,7 +1048,7 @@ License: MIT 16 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys @@ -1056,7 +1056,7 @@ License: MIT 17 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys @@ -1064,7 +1064,7 @@ License: MIT 18 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys @@ -1072,7 +1072,7 @@ License: MIT 19 - Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys diff --git a/zip-0032.rst b/zip-0032.rst index c161b676..0b579b6f 100644 --- a/zip-0032.rst +++ b/zip-0032.rst @@ -25,7 +25,7 @@ The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpret 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.11 of the Zcash +The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. @@ -630,16 +630,16 @@ References .. [#bip-0044] `BIP 44: Multi-Account Hierarchy for Deterministic Wallets `_ .. [#slip-0044] `SLIP 44: Registered coin types for BIP-0044 `_ .. [#bip-0173] `BIP 173: Base32 address format for native v0-16 witness outputs `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.24 or later [NU5 proposal] `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 4.2.2: Sapling Key Components `_ -.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.1.6: DiversifyHash Hash Function `_ -.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature `_ -.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.4.8.3: Jubjub `_ -.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.1: Sprout Shielded Payment Addresses `_ -.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys `_ -.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys `_ -.. [#protocol-saplingspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys `_ -.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys `_ -.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.2: Sapling Key Components `_ +.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions `_ +.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.6.1: Spend Authorization Signature `_ +.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub `_ +.. [#protocol-sproutpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.1: Sprout Payment Addresses `_ +.. [#protocol-sproutspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.2.3: Sprout Spending Keys `_ +.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys `_ +.. [#protocol-saplingspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.4: Sapling Spending Keys `_ +.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys `_ +.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys `_ .. [#NIST-SP-800-38G] `NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption `_ diff --git a/zip-0143.html b/zip-0143.html index 549144ca..536e3e46 100644 --- a/zip-0143.html +++ b/zip-0143.html @@ -360,7 +360,7 @@ sighash: 23652e76cb13b85a0e3363bb5fca061fa791c40c533eccee899364e6e60bb4f7 2 - Zcash Protocol Specification, Version 2020.1.15. Section 4.6: Sending Notes (Sprout) + Zcash Protocol Specification, Version 2021.2.16. Section 4.7.1: Sending Notes (Sprout) diff --git a/zip-0143.rst b/zip-0143.rst index 2623dd28..06ed9540 100644 --- a/zip-0143.rst +++ b/zip-0143.rst @@ -455,7 +455,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-sproutsend] `Zcash Protocol Specification, Version 2020.1.15. Section 4.6: Sending Notes (Sprout) `_ +.. [#protocol-sproutsend] `Zcash Protocol Specification, Version 2021.2.16. Section 4.7.1: Sending Notes (Sprout) `_ .. [#wiki-checksig] `OP\_CHECKSIG. Bitcoin Wiki `_ .. [#quadratic] * `CVE-2013-2292 `_ diff --git a/zip-0155.html b/zip-0155.html index 09d6f0f7..8fe21e68 100644 --- a/zip-0155.html +++ b/zip-0155.html @@ -20,7 +20,7 @@ Pull-Request: <https://githu

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.11 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.

"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).

@@ -196,7 +196,7 @@ CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] // first 2 bytes 2 - Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 3.12 Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet diff --git a/zip-0155.rst b/zip-0155.rst index 910730ac..b79c4b63 100644 --- a/zip-0155.rst +++ b/zip-0155.rst @@ -23,7 +23,7 @@ The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [#zip-0200]_ The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. "P2P network" means the Zcash peer-to-peer network. @@ -236,7 +236,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.2.14 [NU5 proposal]. Section 3.12 Mainnet and Testnet `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet `_ .. [#bip-0155] `BIP 155: addrv2 message `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0239] `ZIP 239: Relay of Version 5 Transactions `_ diff --git a/zip-0173.html b/zip-0173.html index ca9b887b..a01977fe 100644 --- a/zip-0173.html +++ b/zip-0173.html @@ -362,7 +362,7 @@ def bech32_verify_checksum(hrp, data): 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later diff --git a/zip-0173.rst b/zip-0173.rst index 25d85e08..7da69b5b 100644 --- a/zip-0173.rst +++ b/zip-0173.rst @@ -462,7 +462,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_ diff --git a/zip-0203.html b/zip-0203.html index 2f8f091d..1b1e661e 100644 --- a/zip-0203.html +++ b/zip-0203.html @@ -50,7 +50,7 @@ License: MIT

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.

@@ -99,11 +99,11 @@ License: MIT - +
- +
4Zcash Protocol Specification, Version 2020.2.6. Section 7.1: Transaction Encoding and ConsensusZcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus
diff --git a/zip-0203.rst b/zip-0203.rst index 6d6d153e..cb564429 100644 --- a/zip-0203.rst +++ b/zip-0203.rst @@ -93,7 +93,7 @@ NU5 activation [#zip-0252]_, the ``nExpiryHeight`` field of a coinbase transacti 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 [#protocol-txnencodingandconsensus]_. +specification [#protocol-txnencoding]_. Wallet behavior and UI ---------------------- @@ -145,4 +145,4 @@ References .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade `_ .. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade `_ -.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.2.6. Section 7.1: Transaction Encoding and Consensus `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus `_ diff --git a/zip-0205.html b/zip-0205.html index 07f47ec8..99fb4e63 100644 --- a/zip-0205.html +++ b/zip-0205.html @@ -17,7 +17,7 @@ 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.11 of the Zcash Protocol Specification 3.

+

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
@@ -61,7 +61,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;

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.6.4 of that specification 6.

+

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.

@@ -86,7 +86,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later @@ -94,7 +94,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; 3 - Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet @@ -102,7 +102,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; 4 - Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants + Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants @@ -110,7 +110,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; 5 - Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment + Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment @@ -118,7 +118,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; 6 - Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion + Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion diff --git a/zip-0205.rst b/zip-0205.rst index 9a2fd23d..d86ade43 100644 --- a/zip-0205.rst +++ b/zip-0205.rst @@ -20,7 +20,7 @@ The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_ The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. The terms below are to be interpreted as follows: @@ -109,7 +109,7 @@ is greater than 15 minutes after that of the preceding block, then the block is 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 [#protocol-constants]_, and ToCompact is as -defined in section 7.6.4 of that specification [#protocol-nbits]_. +defined in section 7.7.4 of that specification [#protocol-nbits]_. 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 @@ -144,11 +144,11 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants `_ -.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment `_ -.. [#protocol-nbits] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants `_ +.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment `_ +.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling `_ diff --git a/zip-0206.html b/zip-0206.html index 0987a95f..cec9bd0c 100644 --- a/zip-0206.html +++ b/zip-0206.html @@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3; 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later diff --git a/zip-0206.rst b/zip-0206.rst index 23de6d0a..6237d379 100644 --- a/zip-0206.rst +++ b/zip-0206.rst @@ -122,7 +122,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ diff --git a/zip-0207.html b/zip-0207.html index 3dec4eb4..7d72e22c 100644 --- a/zip-0207.html +++ b/zip-0207.html @@ -17,16 +17,16 @@ Created: 2019-01-04 License: MIT

Terminology

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

-

The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. 4 7

+

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:

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. 3
+
The Zcash test network, as defined in the Zcash Protocol Specification. 4
Mainnet
-
The Zcash production network, as defined in the Zcash Protocol Specification. 3
+
The Zcash production network, as defined in the Zcash Protocol Specification. 4

Abstract

@@ -235,23 +235,23 @@ License: MIT 2 - Zcash Protocol Specification, Version 2020.1.15 or later - - - - - - - - +
3Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and TestnetZcash Protocol Specification, Version 2021.2.16 or later
+ + + + + + +
3Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward
+ - +
4Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' RewardZcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet
@@ -259,7 +259,7 @@ License: MIT 5 - Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants + Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants @@ -267,7 +267,7 @@ License: MIT 6 - Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment + Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment @@ -275,7 +275,7 @@ License: MIT 7 - Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward + Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward @@ -283,7 +283,7 @@ License: MIT 8 - Zcash Protocol Specification, Version 2020.1.15. Section 7.8: Payment of Founders' Reward + Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward diff --git a/zip-0207.rst b/zip-0207.rst index 4e0b51de..8ea5611a 100644 --- a/zip-0207.rst +++ b/zip-0207.rst @@ -234,13 +234,13 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward `_ -.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants `_ -.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment `_ -.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward `_ -.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2020.1.15. Section 7.8: Payment of Founders' Reward `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants `_ +.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment `_ +.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward `_ +.. [#protocol-foundersreward] `Zcash Protocol Specification, Version 2021.2.16. Section 7.9: Payment of Founders' Reward `_ .. [#zip-0000] `ZIP 0: ZIP Process `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0208] `ZIP 208: Shorter Block Target Spacing `_ diff --git a/zip-0208.html b/zip-0208.html index fdb6984e..74aac409 100644 --- a/zip-0208.html +++ b/zip-0208.html @@ -20,7 +20,7 @@ Pull-Request: <https://githu

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.11 of the Zcash Protocol Specification 4.

+

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.

@@ -42,7 +42,7 @@ Pull-Request: <https://githu

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.

-

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

+

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.

Define:

@@ -64,7 +64,7 @@ Pull-Request: <https://githu
  • add a height parameter to each of these functions that does not already have one;
  • ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the height parameter.
    • -

    In section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the Halving and BlockSubsidy functions as follows:

    +

    In section 7.7 (Calculation of Block Subsidy and Founders’ Reward) [later moved to section 7.8], redefine the Halving and BlockSubsidy functions as follows:

    Monitoring for quicker- or slower-than-expected blocks

    @@ -223,7 +223,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 3 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later @@ -231,7 +231,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 4 - Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet @@ -239,7 +239,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 5 - Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants + Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants @@ -247,7 +247,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 6 - Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment + Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment @@ -255,7 +255,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 7 - Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion + Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion @@ -263,7 +263,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 8 - Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work + Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work diff --git a/zip-0208.rst b/zip-0208.rst index 7db8f96e..c0a53bc0 100644 --- a/zip-0208.rst +++ b/zip-0208.rst @@ -28,7 +28,7 @@ but "block target spacing" is the term used in the Zcash Protocol Specification [#protocol-diffadjustment]_.) The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. Abstract @@ -84,7 +84,8 @@ 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 [#zip-0206]_. -In section 7.6.3 (Difficulty adjustment), make the following changes: +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. @@ -112,8 +113,8 @@ ActualTimespanDamped, ActualTimespanBounded, and Threshold as follows: - ensure that each reference to any of these values, or to PoWTargetSpacing, are replaced with a function call passing the *height* parameter. -In section 7.7 (Calculation of Block Subsidy and Founders’ Reward), redefine the -Halving and BlockSubsidy functions as follows: +In section 7.7 (Calculation of Block Subsidy and Founders’ Reward) [later moved +to section 7.8], redefine the Halving and BlockSubsidy functions as follows: - Halving(*height*) := @@ -134,7 +135,7 @@ Note: BlossomActivationHeight, PostBlossomHalvingInterval, and PostBlossomTarget - MaxBlockSubsidy / (BlossomPoWTargetSpacingRatio · 2\ :sup:`Halving(*height*)`\ ) is an integer for the next few periods. -In section 7.8 (Payment of Founders’ Reward), define: +In section 7.8 (Payment of Founders’ Reward) [later moved to section 7.9], define: - FounderAddressAdjustedHeight(*height*) := @@ -193,7 +194,7 @@ That is, if the block time of a block at height *height* ≥ 299188 is greater t 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 [#protocol-constants]_, and -ToCompact is as defined in section 7.6.4 of that specification [#protocol-nbits]_. +ToCompact is as defined in section 7.7.4 of that specification [#protocol-nbits]_. Note: a previous revision of this ZIP (and [#zip-0205]_) incorrectly said that only the target threshold of minimum-difficulty blocks is affected. In fact @@ -264,7 +265,7 @@ effectiveness of this mitigation. In any case, to estimate the "best equivalent proof of work" of a given block chain (measured in units of time), we take the total work of the chain as -defined in section 7.6.5 of the Zcash Protocol Specification [#protocol-workdef]_, +defined in section 7.7.5 of the Zcash Protocol Specification [#protocol-workdef]_, divide by the work of the block at the active tip, and multiply by the target block spacing of that block. @@ -395,12 +396,12 @@ References .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#preblossom-protocol] `Zcash Protocol Specification, Version 2018.0-beta-37 (exactly) `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-constants] `Zcash Protocol Specification, Version 2020.1.15. Section 5.3: Constants `_ -.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.3: Difficulty adjustment `_ -.. [#protocol-nbits] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.4: nBits conversion `_ -.. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.15. Section 7.6.5: Definition of Work `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants `_ +.. [#protocol-diffadjustment] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.3: Difficulty adjustment `_ +.. [#protocol-nbits] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.4: nBits conversion `_ +.. [#protocol-workdef] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_ .. [#zip-0206] `ZIP 206: Deployment of the Blossom Network Upgrade `_ diff --git a/zip-0209.html b/zip-0209.html index 8071f52d..065a4e71 100644 --- a/zip-0209.html +++ b/zip-0209.html @@ -20,7 +20,7 @@ License: MIT

    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.11 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.

    @@ -51,7 +51,7 @@ License: MIT 2 - Zcash Protocol Specification, Version 2020.1.15 or later. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet diff --git a/zip-0209.rst b/zip-0209.rst index 5380a2b0..26b85213 100644 --- a/zip-0209.rst +++ b/zip-0209.rst @@ -29,7 +29,7 @@ The "Orchard chain value pool balance" for a given block chain is the negation o ``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.11 of the +The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. @@ -84,6 +84,6 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15 or later. Section 3.11: Mainnet and Testnet `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 or later. Section 3.12: Mainnet and Testnet `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade `_ diff --git a/zip-0210.html b/zip-0210.html index 49e9c4dd..ab0530e8 100644 --- a/zip-0210.html +++ b/zip-0210.html @@ -26,7 +26,7 @@ License: MIT

    Motivation

    The Sapling network upgrade 4 introduced new shielded inputs (spends) and outputs. Each spend proves the existence of the note being spent by including the anchor of a Merkle tree that contains the note's commitment, and proving in zero knowledge the existence of a path from the commitment to the anchor (a witness). Valid anchors correspond to the state of the Sapling commitment tree after each block in the chain.

    -

    The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format 2 includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.

    +

    The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. However, the Sapling v4 transaction format 2 includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet implementations, reducing the privacy set.

    Modifying the transaction format to have a single Sapling anchor field, instead of one field per Sapling spend, removes the ability (within the new transaction format version) to create transactions with this fingerprint. It also reduces the size of the transaction, costing 32 bytes per transaction instead of 32 bytes per spend.

    Specification

    @@ -58,11 +58,11 @@ License: MIT - +
    - +
    2Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and ConsensusZcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus
    diff --git a/zip-0210.rst b/zip-0210.rst index 65ddb310..822335b4 100644 --- a/zip-0210.rst +++ b/zip-0210.rst @@ -49,7 +49,7 @@ correspond to the state of the Sapling commitment tree after each block in the c The choice of anchor leaks information about the note being spent, namely that the note was created no later than the anchor's block height. This is an unavoidable outcome of the Zcash design, and the least information it is possible to leak about a note being spent. -However, the Sapling v4 transaction format [#protocol-txnencodingandconsensus]_ includes +However, the Sapling v4 transaction format [#protocol-txnencoding]_ includes a separate anchor for each Sapling spend, and thus it is possible to leak additional information by using different anchors for different notes. The anchor selection choices could also be used as a fingerprint to identify transactions created by particular wallet @@ -113,7 +113,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_ .. [#zip-0225] `ZIP 225: Version 5 Transaction Format `_ diff --git a/zip-0211.html b/zip-0211.html index a5e05e8b..57aa5b0a 100644 --- a/zip-0211.html +++ b/zip-0211.html @@ -74,7 +74,7 @@ License: MIT 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later diff --git a/zip-0211.rst b/zip-0211.rst index f68f7c48..e947c62d 100644 --- a/zip-0211.rst +++ b/zip-0211.rst @@ -144,7 +144,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_ .. [#zip-0209] `ZIP 209: Prohibit Negative Shielded Value Pool `_ diff --git a/zip-0212.html b/zip-0212.html index 0d452df6..76709197 100644 --- a/zip-0212.html +++ b/zip-0212.html @@ -113,8 +113,8 @@ License: MIT .

    Specification

    -

    The specification in this ZIP is intended to be aligned with version 2021.2.6 or later of the Zcash Protocol Specification 2.

    -

    Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification 3. We will be adapting +

    The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification 2.

    +

    Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification 3. We will be adapting \(\mathsf{PRF^{expand}}\) for the purposes of this ZIP. This function is keyed by a 256-bit key \(\mathsf{sk}\) @@ -292,7 +292,7 @@ License: MIT 2 - Zcash Protocol Specification, Version 2021.2.6 or later + Zcash Protocol Specification, Version 2021.2.16 or later @@ -300,7 +300,7 @@ License: MIT 3 - Zcash Protocol Specification, Version 2021.2.6. Section 4.1.2: Pseudo Random Functions + Zcash Protocol Specification, Version 2021.2.16. Section 4.1.2: Pseudo Random Functions @@ -308,7 +308,7 @@ License: MIT 4 - Zcash Protocol Specification, Version 2021.2.6. Section 4.1.8: Commitment + Zcash Protocol Specification, Version 2021.2.16. Section 4.1.8: Commitment @@ -316,7 +316,7 @@ License: MIT 5 - Zcash Protocol Specification, Version 2021.2.6. Section 4.2.2: Sapling Key Components + Zcash Protocol Specification, Version 2021.2.16. Section 4.2.2: Sapling Key Components @@ -324,7 +324,7 @@ License: MIT 6 - Zcash Protocol Specification, Version 2021.2.6. Section 4.2.3: Orchard Key Components + Zcash Protocol Specification, Version 2021.2.16. Section 4.2.3: Orchard Key Components @@ -332,7 +332,7 @@ License: MIT 7 - Zcash Protocol Specification, Version 2021.2.6. Section 4.7.2: Sending Notes (Sapling) + Zcash Protocol Specification, Version 2021.2.16. Section 4.7.2: Sending Notes (Sapling) @@ -340,7 +340,7 @@ License: MIT 8 - Zcash Protocol Specification, Version 2021.2.6. Section 4.7.3: Sending Notes (Orchard) + Zcash Protocol Specification, Version 2021.2.16. Section 4.7.3: Sending Notes (Orchard) @@ -348,7 +348,7 @@ License: MIT 9 - Zcash Protocol Specification, Version 2021.2.6. Section 4.19.1: Encryption (Sapling and Orchard) + Zcash Protocol Specification, Version 2021.2.16. Section 4.19.1: Encryption (Sapling and Orchard) @@ -356,7 +356,7 @@ License: MIT 10 - Zcash Protocol Specification, Version 2021.2.6. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard) + Zcash Protocol Specification, Version 2021.2.16. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard) @@ -364,7 +364,7 @@ License: MIT 11 - Zcash Protocol Specification, Version 2021.2.6. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard) + Zcash Protocol Specification, Version 2021.2.16. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard) @@ -372,7 +372,7 @@ License: MIT 12 - Zcash Protocol Specification, Version 2021.2.6. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions + Zcash Protocol Specification, Version 2021.2.16. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions @@ -380,7 +380,7 @@ License: MIT 13 - Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.3 Sapling Key Agreement + Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.3 Sapling Key Agreement @@ -388,7 +388,7 @@ License: MIT 14 - Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.5 Orchard Key Agreement + Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.5 Orchard Key Agreement @@ -396,7 +396,7 @@ License: MIT 15 - Zcash Protocol Specification, Version 2021.2.6. Section 5.5: Encodings of Note Plaintexts and Memo Fields + Zcash Protocol Specification, Version 2021.2.16. Section 5.5: Encodings of Note Plaintexts and Memo Fields diff --git a/zip-0212.rst b/zip-0212.rst index 88f29bdd..83422508 100644 --- a/zip-0212.rst +++ b/zip-0212.rst @@ -112,10 +112,10 @@ concerns by using a key derivation to obtain both :math:`\mathsf{esk}` and Specification ============= -The specification in this ZIP is intended to be aligned with version 2021.2.6 +The specification in this ZIP is intended to be aligned with version 2021.2.16 or later of the Zcash Protocol Specification [#protocol]_. -Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash +Pseudo random functions (PRFs) are defined in section 4.1.2 of the Zcash Protocol Specification [#protocol-abstractprfs]_. We will be adapting :math:`\mathsf{PRF^{expand}}` for the purposes of this ZIP. This function is keyed by a 256-bit key :math:`\mathsf{sk}` and takes an arbitrary length byte @@ -325,20 +325,20 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2021.2.6 or later `_ -.. [#protocol-abstractprfs] `Zcash Protocol Specification, Version 2021.2.6. Section 4.1.2: Pseudo Random Functions `_ -.. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2021.2.6. Section 4.1.8: Commitment `_ -.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2021.2.6. Section 4.2.2: Sapling Key Components `_ -.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.2.6. Section 4.2.3: Orchard Key Components `_ -.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2021.2.6. Section 4.7.2: Sending Notes (Sapling) `_ -.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2021.2.6. Section 4.7.3: Sending Notes (Orchard) `_ -.. [#protocol-saplingandorchardencrypt] `Zcash Protocol Specification, Version 2021.2.6. Section 4.19.1: Encryption (Sapling and Orchard) `_ -.. [#protocol-decryptivk] `Zcash Protocol Specification, Version 2021.2.6. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard) `_ -.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.2.6. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard) `_ -.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2021.2.6. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions `_ -.. [#protocol-concretesaplingkeyagreement] `Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.3 Sapling Key Agreement `_ -.. [#protocol-concreteorchardkeyagreement] `Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.5 Orchard Key Agreement `_ -.. [#protocol-notept] `Zcash Protocol Specification, Version 2021.2.6. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-abstractprfs] `Zcash Protocol Specification, Version 2021.2.16. Section 4.1.2: Pseudo Random Functions `_ +.. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2021.2.16. Section 4.1.8: Commitment `_ +.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2021.2.16. Section 4.2.2: Sapling Key Components `_ +.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.2.16. Section 4.2.3: Orchard Key Components `_ +.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2021.2.16. Section 4.7.2: Sending Notes (Sapling) `_ +.. [#protocol-orchardsend] `Zcash Protocol Specification, Version 2021.2.16. Section 4.7.3: Sending Notes (Orchard) `_ +.. [#protocol-saplingandorchardencrypt] `Zcash Protocol Specification, Version 2021.2.16. Section 4.19.1: Encryption (Sapling and Orchard) `_ +.. [#protocol-decryptivk] `Zcash Protocol Specification, Version 2021.2.16. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard) `_ +.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.2.16. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard) `_ +.. [#protocol-concretediversifyhash] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions `_ +.. [#protocol-concretesaplingkeyagreement] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.3 Sapling Key Agreement `_ +.. [#protocol-concreteorchardkeyagreement] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.5.5 Orchard Key Agreement `_ +.. [#protocol-notept] `Zcash Protocol Specification, Version 2021.2.16. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ .. [#zip-0207] `ZIP 207: Split Founders' Reward `_ .. [#zip-0213] `ZIP 213: Shielded Coinbase `_ .. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade `_ diff --git a/zip-0213.rst b/zip-0213.rst index 3126c30a..fea99b37 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -24,6 +24,7 @@ The term "Sapling" in this document is to be interpreted as described in ZIP 205 The terms "Founders' Reward" and "funding stream" in this document are to be interpreted as described in ZIP 207 [#zip-0207]_. + Abstract ======== diff --git a/zip-0214.html b/zip-0214.html index 8e5877ce..4eed82bf 100644 --- a/zip-0214.html +++ b/zip-0214.html @@ -18,10 +18,10 @@ Discussions-To: <1

    The term "Zcash" in this document is to be interpreted as described in the Zcash Trademark Donation and License Agreement (6 or successor agreement).

    The term "network upgrade" in this document is to be interpreted as described in ZIP 200 8 and the Zcash Trademark Donation and License Agreement (6 or successor agreement).

    -

    The term "block subsidy" in this document is to be interpreted as described in section 3.9 of the Zcash Protocol Specification 4.

    -

    The term "halving" in this document are to be interpreted as described in sections 7.7 of the Zcash Protocol Specification 5.

    +

    The term "block subsidy" in this document is to be interpreted as described in section 3.10 of the Zcash Protocol Specification 3.

    +

    The term "halving" in this document are to be interpreted as described in sections 7.8 of the Zcash Protocol Specification 5.

    The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and "MG slice" in this document are to be interpreted as described in ZIP 1014 12.

    -

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

    +

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

    "Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.

    Abstract

    @@ -279,23 +279,23 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51 2 - Zcash Protocol Specification, Version 2020.1.15 or later - - - - - - - - +
    3Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and TestnetZcash Protocol Specification, Version 2021.2.16 or later
    + + + + + + +
    3Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward
    + - +
    4Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' RewardZcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet
    @@ -303,7 +303,7 @@ FS_ZIP214_MG.AddressList[0..50] = ["t2Gvxv2uNM7hbbACjNox4H6DjByoKZ2Fa3P"] * 51 5 - Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward + Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward diff --git a/zip-0214.rst b/zip-0214.rst index 56b95a40..94683cd8 100644 --- a/zip-0214.rst +++ b/zip-0214.rst @@ -25,10 +25,10 @@ described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor agreement). The term "block subsidy" in this document is to be interpreted as described in -section 3.9 of the Zcash Protocol Specification [#protocol-subsidyconcepts]_. +section 3.10 of the Zcash Protocol Specification [#protocol-subsidyconcepts]_. The term "halving" in this document are to be interpreted as described in -sections 7.7 of the Zcash Protocol Specification [#protocol-subsidies]_. +sections 7.8 of the Zcash Protocol Specification [#protocol-subsidies]_. The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), "Zcash Foundation" (or "ZF"), "Major Grants", "BP slice", "ZF slice", and @@ -36,7 +36,7 @@ The terms "Bootstrap Project" (or "BP"), "Electric Coin Company" (or "ECC"), [#zip-1014]_. The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. "Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4. @@ -337,10 +337,10 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2020.1.15. Section 3.9: Block Subsidy and Founders' Reward `_ -.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2020.1.15. Section 7.7: Calculation of Block Subsidy and Founders' Reward `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-subsidyconcepts] `Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy, Funding Streams, and Founders' Reward `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-subsidies] `Zcash Protocol Specification, Version 2021.2.16. Section 7.8: Calculation of Block Subsidy, Funding Streams, and Founders' Reward `_ .. [#trademark] `Zcash Trademark Donation and License Agreement `_ .. [#osd] `The Open Source Definition `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ diff --git a/zip-0215.html b/zip-0215.html index 8ffdefef..2a15646f 100644 --- a/zip-0215.html +++ b/zip-0215.html @@ -108,7 +108,7 @@ License: BSD-2-Clause 4 - Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet @@ -116,7 +116,7 @@ License: BSD-2-Clause 5 - Zcash Protocol Specification, Version 2020.1.15. Section 5.4.5: Ed25519 + Zcash Protocol Specification, Version 2021.2.16. Section 5.4.6: Ed25519 diff --git a/zip-0215.rst b/zip-0215.rst index 56c711d6..f8389515 100644 --- a/zip-0215.rst +++ b/zip-0215.rst @@ -114,6 +114,6 @@ References .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#RFC8032] `RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA) `_ .. [#protocol-2020.1.1] `Zcash Protocol Specification, Version 2020.1.1 `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-concreteed25519] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.5: Ed25519 `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-concreteed25519] `Zcash Protocol Specification, Version 2021.2.16. Section 5.4.6: Ed25519 `_ .. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade `_ diff --git a/zip-0216.html b/zip-0216.html index 2911b24e..59eaa5fd 100644 --- a/zip-0216.html +++ b/zip-0216.html @@ -92,7 +92,7 @@ Discussions-To: <https://g RedDSA signature. -

    In transactions 10:

    +

    In transactions 10:

    • the @@ -116,7 +116,7 @@ Discussions-To: <https://g

    (This affects decryption of \(\mathsf{C^{out}}\) - in all cases, but is consensus-critical only in the case of a shielded coinbase output. 10)

    + in all cases, but is consensus-critical only in the case of a shielded coinbase output. 10)

    There are some additional fields in the consensus protocol that encode Jubjub points, but where non-canonical encodings MUST already be rejected as a side-effect of existing consensus rules.

    In Sapling Spend descriptions:

    @@ -218,7 +218,7 @@ Discussions-To: <https://g 2 - Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal] + Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] @@ -226,7 +226,7 @@ Discussions-To: <https://g 3 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions @@ -234,7 +234,7 @@ Discussions-To: <https://g 4 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions @@ -242,7 +242,7 @@ Discussions-To: <https://g 5 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) @@ -250,7 +250,7 @@ Discussions-To: <https://g 6 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.3: Jubjub + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub @@ -258,7 +258,7 @@ Discussions-To: <https://g 7 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta @@ -266,7 +266,7 @@ Discussions-To: <https://g 8 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses @@ -274,15 +274,15 @@ Discussions-To: <https://g 9 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys - +
    - +
    10Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and ConsensusZcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus
    diff --git a/zip-0216.rst b/zip-0216.rst index 33bef5a5..f21d47c3 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -101,7 +101,7 @@ In Sapling Spend descriptions [#protocol-spenddesc]_: - the :math:`\underline{R}` component (i.e. the first :math:`32` bytes) of the :math:`\mathtt{spendAuthSig}` RedDSA signature. -In transactions [#protocol-txnencodingandconsensus]_: +In transactions [#protocol-txnencoding]_: - the :math:`\underline{R}` component (i.e. the first :math:`32` bytes) of the :math:`\mathtt{bindingSigSapling}` RedDSA signature. @@ -113,7 +113,7 @@ Sapling transmitted note ciphertext [#protocol-decryptovk]_: (This affects decryption of :math:`\mathsf{C^{out}}` in all cases, but is consensus-critical only in the case of a shielded coinbase output. -[#protocol-txnencodingandconsensus]_) +[#protocol-txnencoding]_) There are some additional fields in the consensus protocol that encode Jubjub points, but where non-canonical encodings MUST already be rejected as a side-effect of @@ -215,15 +215,15 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal] `_ -.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions `_ -.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions `_ -.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) `_ -.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.3: Jubjub `_ -.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ -.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ -.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys `_ -.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] `_ +.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions `_ +.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions `_ +.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) `_ +.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ +.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ +.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ .. [#zip-0032-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets. Sapling extended full viewing keys `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0215] `ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules `_ diff --git a/zip-0221.html b/zip-0221.html index 96c8634b..d219ca81 100644 --- a/zip-0221.html +++ b/zip-0221.html @@ -657,7 +657,6 @@ License: MIT
  • Mimblewimble MMR docs
  • MMR Python implementation
  • Tari MMR documentation
    • -
  • Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later
  • opentimestamps-server Merkle Mountain Range documentation
    • @@ -682,7 +681,7 @@ License: MIT 3 - Zcash Protocol Specification, Version 2020.1.24. Section 7.6.5: Definition of Work + Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work @@ -690,7 +689,7 @@ License: MIT 4 - Zcash Protocol Specification, Version 2020.1.24. Section 7.5: Block Header + Zcash Protocol Specification, Version 2021.2.16. Section 7.6: Block Header Encoding and Consensus diff --git a/zip-0221.rst b/zip-0221.rst index e9255bcd..366a9c48 100644 --- a/zip-0221.rst +++ b/zip-0221.rst @@ -11,6 +11,7 @@ Created: 2019-03-30 License: MIT + Terminology =========== @@ -820,7 +821,6 @@ Additional Reading - `Mimblewimble MMR docs `_ - `MMR Python implementation `_ - `Tari MMR documentation `_ -- `Zcash Protocol Specification, Version 2020.1.1 [Overwinter+Sapling+Blossom] or later `_ - `opentimestamps-server Merkle Mountain Range documentation `_ @@ -829,8 +829,8 @@ References .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#FlyClient] `FlyClient protocol `_ -.. [#protocol-workdef] `Zcash Protocol Specification, Version 2020.1.24. Section 7.6.5: Definition of Work `_ -.. [#protocol-blockheader] `Zcash Protocol Specification, Version 2020.1.24. Section 7.5: Block Header `_ +.. [#protocol-workdef] `Zcash Protocol Specification, Version 2021.2.16. Section 7.7.5: Definition of Work `_ +.. [#protocol-blockheader] `Zcash Protocol Specification, Version 2021.2.16. Section 7.6: Block Header Encoding and Consensus `_ .. [#zcashBlock] `Zcash block primitive `_ .. [#mimblewimble] `MimbleWimble Grin MMR implementation `_ .. [#bip-0034] `BIP 34: Block v2, Height in Coinbase `_ diff --git a/zip-0222.html b/zip-0222.html index 7f246a0c..c5b2073f 100644 --- a/zip-0222.html +++ b/zip-0222.html @@ -19,16 +19,16 @@ Created: 2019-07-01 License: MIT

    Terminology

    The key words "MUST" 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 2.

    +

    The term "network upgrade" in this document is to be interpreted as described in ZIP 200 6.

    The term "prefix-free" in this document is to be interpreted as to mean that no valid encoding of a value may have the same binary representation as any prefix of the binary encoding of another value of the same type.

    -

    The term "non-malleable" in this document is to be interpreted as described in ZIP 244 3.

    -

    The value MAX_MONEY is as defined in section 5.3 'Constants' of the Zcash Protocol Specification 8.

    +

    The term "non-malleable" in this document is to be interpreted as described in ZIP 244 7.

    +

    The value MAX_MONEY is as defined in section 5.3 of the Zcash Protocol Specification 3.

    Abstract

    This proposal defines a modification to the consensus rules that enables complex forms of transparent output preconditions to be deployed in network upgrades. This in turn enables the creation of "transparent Zcash extensions" that augment the network's functionality in a carefully-defined and auditable fashion.

    Motivation

    -

    Zcash supports a limited set of preconditions that may be imposed upon how funds, both transparent and shielded, may be spent. Spending limitations on transparent funds are defined by what may be encoded in Bitcoin script, and spending of shielded funds is even more restricted. As such, some use cases (for example, integration of BOLT support 5) are not yet supportable.

    +

    Zcash supports a limited set of preconditions that may be imposed upon how funds, both transparent and shielded, may be spent. Spending limitations on transparent funds are defined by what may be encoded in Bitcoin script, and spending of shielded funds is even more restricted. As such, some use cases (for example, integration of BOLT support 9) are not yet supportable.

    Transparent Zcash Extensions are intended to make it possible to incrementally add new functionality without modifying interpretation of the existing Bitcoin script, which is complex and potentially error-prone. Extensions may also serve as laboratories for evaluating demand for functionality which may eventually be candidates for inclusion in the consensus rules for shielded transactions.

    Definitions

    @@ -249,7 +249,7 @@ License: MIT
  • Non-coinbase transactions MUST have at least one of the following: - nonempty transparent inputs - nonempty shielded inputs - nonempty tze_inputs

    • The above rule replaces [Sapling onward] At least one of tx_in_count, -nShieldedSpend, and nJoinSplit MUST be nonzero in 9.

    +nShieldedSpend, and nJoinSplit MUST be nonzero in 4.

    • Transactions MUST have at least one of the following: - nonempty transparent outputs - nonempty shielded outputs - nonempty tze_outputs
    • All amount field values of tze_output records MUST be nonnegative and not greater than MAX_MONEY.
      • @@ -257,8 +257,8 @@ nShieldedSpend, and nJoinSplit MUST be nonzero in

      Changes to signatures over transaction digests

      -

      This ZIP MUST be deployed in conjunction with or after ZIP 244 3, which defines new non-malleable transaction identifier and signature digest algorithms.

      -

      The newly added parts of the transaction, excluding witness information (i.e. not the witness fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 4 for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.

      +

      This ZIP MUST be deployed in conjunction with or after ZIP 244 7, which defines new non-malleable transaction identifier and signature digest algorithms.

      +

      The newly added parts of the transaction, excluding witness information (i.e. not the witness fields of TZE Input Encodings), will be included in transaction digests for transaction identifiers and signatures. See ZIP 245 8 for the specification of these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well.

    Rationale

    @@ -294,10 +294,42 @@ nShieldedSpend, and nJoinSplit MUST be nonzero in + + + + +
    2Zcash Protocol Specification, Version 2021.2.16 or later
    + + + + + + + +
    3Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants
    + + + + + + + +
    4Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Consensus Rules
    + + + + + + + +
    5ZIP 32: Shielded Hierarchical Deterministic Wallets
    + + + + @@ -305,7 +337,7 @@ nShieldedSpend, and nJoinSplit MUST be nonzero in - + @@ -313,48 +345,16 @@ nShieldedSpend, and nJoinSplit MUST be nonzero in - +
    6 ZIP 200: Network Upgrade Mechanism
    37 ZIP 244: Transaction Non-Malleability Support
    48 ZIP 245: Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions
    - - - - - - -
    5Draft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol
    - - - - - - - -
    6Section 2: Notation. Zcash Protocol Specification, Version 2019.0.2 [Overwinter+Sapling]
    - - - - - - - -
    7ZIP 32: Shielded Hierarchical Deterministic Wallets
    - - - - - - - -
    8Zcash Protocol Specification, Version 2020.1.15 or later
    - - +
    9Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and ConsensusDraft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol
    diff --git a/zip-0222.rst b/zip-0222.rst index c0e2276e..d590f934 100644 --- a/zip-0222.rst +++ b/zip-0222.rst @@ -29,8 +29,9 @@ the binary encoding of another value of the same type. The term "non-malleable" in this document is to be interpreted as described in ZIP 244 [#zip-0244]_. -The value ``MAX_MONEY`` is as defined in section *5.3 'Constants'* of the Zcash Protocol -Specification [#protocol]_. +The value ``MAX_MONEY`` is as defined in section 5.3 of the Zcash Protocol Specification +[#protocol-constants]_. + Abstract ======== @@ -40,6 +41,7 @@ transparent output preconditions to be deployed in network upgrades. This in tur creation of "transparent Zcash extensions" that augment the network's functionality in a carefully-defined and auditable fashion. + Motivation ========== @@ -55,6 +57,7 @@ script, which is complex and potentially error-prone. Extensions may also serve as laboratories for evaluating demand for functionality which may eventually be candidates for inclusion in the consensus rules for shielded transactions. + Definitions =========== @@ -69,6 +72,7 @@ precondition witness Evidence to be evaluated against the challenge encoded by a precondition. + Specification ============= @@ -225,7 +229,7 @@ Once this ZIP becomes active, the following new consensus rules are enforced: - nonempty ``tze_inputs`` The above rule replaces ``[Sapling onward] At least one of tx_in_count, -nShieldedSpend, and nJoinSplit MUST be nonzero`` in [#protocol_consensus]_. +nShieldedSpend, and nJoinSplit MUST be nonzero`` in [#protocol-txnconsensus]_. - Transactions MUST have at least one of the following: - nonempty transparent outputs @@ -252,6 +256,7 @@ transaction identifiers and signatures. See ZIP 245 [#zip-0245]_ for the specif these new digests. If the changes in this ZIP are deployed, those described in ZIP 245 MUST be deployed as well. + Rationale ========= @@ -317,13 +322,13 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-constants] `Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants `_ +.. [#protocol-txnconsensus] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Consensus Rules `_ +.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0244] `ZIP 244: Transaction Non-Malleability Support `_ .. [#zip-0245] `ZIP 245: Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions `_ .. [#zip-draft-bolt] `Draft ZIP: Add support for Blind Off-chain Lightweight Transactions (Bolt) protocol `_ -.. [#spec-notation] `Section 2: Notation. Zcash Protocol Specification, Version 2019.0.2 [Overwinter+Sapling] `_ -.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ -.. [#protocol_consensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus `_ .. [#librustzcash_zip222] `Rust language reference implementation of TZE API `_ .. [#zcashd_zip222] `zcashd reference implementation of consensus rule changes `_ diff --git a/zip-0224.html b/zip-0224.html index 38cef8ef..3ffc34b5 100644 --- a/zip-0224.html +++ b/zip-0224.html @@ -21,7 +21,7 @@ License: MIT Discussions-To: <    https://github.com/zcash/zips/issues/435>

    Terminology

    The key word "MUST" in this document is to be interpreted as described in RFC 2119. 1

    -

    The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of 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 5.

    Abstract

    This document proposes the Orchard shielded protocol, which defines a new shielded pool with spending keys and payment addresses that are amenable to future scalability improvements.

    @@ -29,18 +29,18 @@ Discussions-To: <https://g

    Motivation

    Zcash currently has two active shielded protocols and associated shielded pools:

      -
    • The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes 2), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.
      • +
    • The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes 21), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.
    • The Sapling shielded protocol, which consisted of numerous improvements to functionality and improved performance by orders of magnitude, and as of Feburary 2021 is the "active" shielded pool.

    Both of these shielded protocols suffer from two issues:

    • Neither Sprout nor Sapling are compatible with known efficient scalability techniques. Recursive zero-knowledge proofs (where a proof verifies an earlier instance of itself along with new state) that are suitable for deployment in a block chain like Zcash require a cycle of elliptic curves. The Sprout protocol does not use elliptic curves and thus is an inherently inefficient protocol to implement inside a circuit, while the Sapling protocol uses curves for which there is no known way to construct an efficient curve cycle (or path to one).
      • -
    • The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later 3), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, 4 which needed to be resolved by changing the proving system and running a new MPC.
      • +
    • The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later 2), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, 3 which needed to be resolved by changing the proving system and running a new MPC.

    We are thus motivated to deploy a new shielded protocol designed around a curve cycle, using a proving system that is both amenable to recursion and does not require an SRS.

    Specification

    -

    The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification 5.

    +

    The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification 4.

    Given that the Orchard protocol largely follows the design of the Sapling protocol, we provide here a list of differences, with references to their normative specifications and associated design rationale.

    Curves

    The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its embedded curve Jubjub:

    @@ -53,43 +53,38 @@ Discussions-To: <https://g , instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow (version 10 of) the IETF hash-to-curve Internet Draft 33 (but the protocol specification takes precedence in the case of any discrepancy).

    The presence of the curve cycle is an explicit design choice. This proposal only uses half of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future protocol updates.

      -
    • Curve specifications: 16
      • +
    • Curve specifications: 15
    • \(\mathsf{GroupHash}\) - : 17
      • + : 16
    • Supporting evidence: 34

    Proving system

    -

    Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), instead of Groth16 and R1CS.

    +

    Orchard uses the Halo 2 proving system 23 with the PLONKish arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS.

    This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates.

    -
      -
    • Halo 2 protocol description: TODO
      • -
    • UltraPLONK Arithmetization: 22
      • -
    • Halo 2 explanation and design rationale: 23
      • -

    Circuit

    Orchard uses a single circuit for both spends and outputs, similar to Sprout. An "action" contains both a single (possibly dummy) note being spent, and a single (possibly dummy) note being created.

    An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that covers all of the actions in the bundle.

      -
    • Action description: 9
      • -
    • Circuit statement: 10
      • -
    • Design rationale: 25
      • +
    • Action description: 8
      • +
    • Circuit statement: 9
      • +
    • Design rationale: 25

    Commitments

    -

    The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the UPA-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.

    +

    The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic commitments, Orchard uses the PLONKish-efficient Sinsemilla in place of Bowe–Hopwood Pedersen hashes.

      -
    • Sinsemilla hash function: 12
      • -
    • Sinsemilla commitments: 15
      • -
    • Design rationale: 26
      • +
    • Sinsemilla hash function: 11
      • +
    • Sinsemilla commitments: 14
      • +
    • Design rationale: 26

    Commitment tree

    Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe–Hopwood Pedersen hash.

      -
    • Design rationale and considered alternatives: 27
      • +
    • Design rationale and considered alternatives: 27

    Keys and addresses

    @@ -110,14 +105,14 @@ Discussions-To: <https://g , instead of being a component of the spending key.
  • All diversifiers now result in valid payment addresses.
    • -

    There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in 32. Orchard spending keys are encoded using Bech32m as specified in 21.

    +

    There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in 32. Orchard spending keys are encoded using Bech32m as specified in 20.

    Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt the Sapling HD mechanism from ZIP 32 to Orchard; instead, we define a hardened-only derivation mechanism (similar to Sprout).

      -
    • Key components diagram: 7
      • -
    • Key components specification: 11
      • -
    • Encodings and HRPs: 18 19 20 21
      • -
    • HD key derivation specification: 29
      • -
    • Design rationale: 24
      • +
    • Key components diagram: 6
      • +
    • Key components specification: 10
      • +
    • Encodings: 17 18 19 20
      • +
    • HD key derivation specification: 29
      • +
    • Design rationale: 24

    Notes

    @@ -128,9 +123,9 @@ Discussions-To: <https://g \(\psi\) and \(\mathsf{rcm}\) - are derived from a random seed (as with Sapling after ZIP 212 30).

    + are derived from a random seed (as with Sapling after ZIP 212 30).

      -
    • Orchard notes: 8
      • +
    • Orchard notes: 7

    Nullifiers

    @@ -144,14 +139,14 @@ Discussions-To: <https://g \(\mathcal{G}\) is a fixed independent base.

      -
    • Poseidon: 13
      • -
    • Design rationale and considered alternatives: 28
      • +
    • Poseidon: 12
      • +
    • Design rationale and considered alternatives: 28

    Signatures

    Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).

      -
    • RedPallas: 14
      • +
    • RedPallas: 13
    @@ -171,7 +166,7 @@ Discussions-To: <https://g field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.
  • Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
    • @@ -199,18 +194,10 @@ Discussions-To: <https://g - - - - - - - -
    2Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper
    - + @@ -218,7 +205,7 @@ Discussions-To: <https://g
    32 Parameter Generation
    - + @@ -226,148 +213,156 @@ Discussions-To: <https://g
    43 Zcash Counterfeiting Vulnerability Successfully Remediated
    - - + +
    5Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal]4Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]
    - - + +
    6Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet5Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet
    - - + +
    7Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.1: Payment Addresses and Keys6Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys
    - - + +
    8Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.2: Notes7Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes
    - - + +
    9Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions8Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions
    - - + +
    10Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)9Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)
    - - + +
    11Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.2.3: Orchard Key Components10Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.3: Orchard Key Components
    - - + +
    12Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function11Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function
    - - + +
    13Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function12Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function
    - - + +
    14Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas13Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas
    - - + +
    15Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.7.4: Sinsemilla commitments14Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments
    - - + +
    16Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.6: Pallas and Vesta15Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta
    - - + +
    17Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta16Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta
    - - + +
    18Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.1: Orchard Payment Address17Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses
    - - + +
    19Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys18Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys
    - - + +
    20Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys19Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys
    - - + +
    21Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys20Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys
    - +
    + + + + + + +
    21Zcash Protocol Specification, Version 2021.2.16. Section 8: Differences from the Zerocash paper
    + - +
    22The halo2 Book: 1.2 UltraPLONK ArithmetizationThe halo2 Book: 1.2 PLONKish Arithmetization
    - +
    @@ -375,7 +370,7 @@ Discussions-To: <https://g
    23
    - +
    @@ -383,7 +378,7 @@ Discussions-To: <https://g
    24
    - +
    @@ -391,7 +386,7 @@ Discussions-To: <https://g
    25
    - +
    @@ -399,7 +394,7 @@ Discussions-To: <https://g
    26
    - +
    @@ -407,7 +402,7 @@ Discussions-To: <https://g
    27
    - +
    diff --git a/zip-0224.rst b/zip-0224.rst index b334c7b6..ba8927ac 100644 --- a/zip-0224.rst +++ b/zip-0224.rst @@ -19,8 +19,8 @@ Terminology The key word "MUST" in this document is to be interpreted as described in RFC 2119. [#RFC2119]_ -The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash -Protocol Specification [#protocol-networks]_. +The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of +the Zcash Protocol Specification [#protocol-networks]_. Abstract @@ -37,7 +37,7 @@ Motivation Zcash currently has two active shielded protocols and associated shielded pools: - The Sprout shielded protocol (based on the Zerocash paper with improvements and security - fixes [#zerocash-differences]_), which as of February 2021 is a "closing" shielded pool + fixes [#protocol-differences]_), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent. - The Sapling shielded protocol, which consisted of numerous improvements to functionality and improved performance by orders of magnitude, and as of Feburary 2021 is the "active" @@ -107,16 +107,12 @@ leveraged by future protocol updates. Proving system -------------- -Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), instead -of Groth16 and R1CS. +Orchard uses the Halo 2 proving system [#halo2-proving-system]_ with the PLONKish +arithmetization [#halo2-arithmetization], instead of Groth16 and R1CS. This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates. -- Halo 2 protocol description: TODO -- UltraPLONK Arithmetization: [#concepts-upa]_ -- Halo 2 explanation and design rationale: [#design-halo2]_ - Circuit ------- @@ -129,18 +125,18 @@ covers all of the actions in the bundle. - Action description: [#protocol-actions]_ - Circuit statement: [#protocol-actionstatement]_ -- Design rationale: [#design-actions]_ +- Design rationale: [#orchard-actions]_ Commitments ----------- The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic -commitments, Orchard uses the UPA-efficient Sinsemilla in place of Bowe–Hopwood Pedersen -hashes. +commitments, Orchard uses the PLONKish-efficient Sinsemilla in place of Bowe–Hopwood +Pedersen hashes. - Sinsemilla hash function: [#protocol-concretesinsemillahash]_ - Sinsemilla commitments: [#protocol-concretesinsemillacommit]_ -- Design rationale: [#design-commitments]_ +- Design rationale: [#orchard-commitments]_ Commitment tree --------------- @@ -148,7 +144,7 @@ Commitment tree Orchard uses an identical commitment tree structure to Sapling, except that we instantiate it with Sinsemilla instead of a Bowe–Hopwood Pedersen hash. -- Design rationale and considered alternatives: [#design-tree]_ +- Design rationale and considered alternatives: [#orchard-tree]_ Keys and addresses ------------------ @@ -175,10 +171,10 @@ derivation mechanism (similar to Sprout). - Key components diagram: [#protocol-addressesandkeys]_ - Key components specification: [#protocol-orchardkeycomponents]_ -- Encodings and HRPs: [#protocol-orchardpaymentaddrencoding]_ [#protocol-orchardinviewingkeyencoding]_ [#protocol-orchardfullviewingkeyencoding]_ - [#protocol-orchardspendingkeyencoding]_ +- Encodings: [#protocol-orchardpaymentaddrencoding]_ [#protocol-orchardinviewingkeyencoding]_ + [#protocol-orchardfullviewingkeyencoding]_ [#protocol-orchardspendingkeyencoding]_ - HD key derivation specification: [#zip-0032]_ -- Design rationale: [#design-keys]_ +- Design rationale: [#orchard-keys]_ Notes ----- @@ -201,7 +197,7 @@ where :math:`F` is instantiated with Poseidon, and :math:`\mathcal{G}` is a fixe independent base. - Poseidon: [#protocol-poseidonhash]_ -- Design rationale and considered alternatives: [#design-nullifiers]_ +- Design rationale and considered alternatives: [#orchard-nullifiers]_ Signatures ---------- @@ -283,33 +279,33 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#zerocash-differences] `Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper `_ .. [#zcash-paramgen] `Parameter Generation `_ .. [#bctv14-vuln] `Zcash Counterfeiting Vulnerability Successfully Remediated `_ -.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal] `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.1: Payment Addresses and Keys `_ -.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.2: Notes `_ -.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ -.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ -.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.2.3: Orchard Key Components `_ -.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function `_ -.. [#protocol-poseidonhash] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function `_ -.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas `_ -.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.7.4: Sinsemilla commitments `_ -.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.6: Pallas and Vesta `_ -.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta `_ -.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.1: Orchard Payment Address `_ -.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys `_ -.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.3: Orchard Full Viewing Keys `_ -.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 5.6.4.4: Orchard Spending Keys `_ -.. [#concepts-upa] `The halo2 Book: 1.2 UltraPLONK Arithmetization `_ -.. [#design-halo2] `The halo2 Book: 3.1. Proving system `_ -.. [#design-keys] `The Orchard Book: 3.1. Keys and addresses `_ -.. [#design-actions] `The Orchard Book: 3.2. Actions `_ -.. [#design-commitments] `The Orchard Book: 3.3. Commitments `_ -.. [#design-tree] `The Orchard Book: 3.4. Commitment tree `_ -.. [#design-nullifiers] `The Orchard Book: 3.5. Nullifiers `_ +.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys `_ +.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes `_ +.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions `_ +.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard) `_ +.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.3: Orchard Key Components `_ +.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function `_ +.. [#protocol-poseidonhash] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function `_ +.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas `_ +.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ +.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta `_ +.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses `_ +.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys `_ +.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys `_ +.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys `_ +.. [#protocol-differences] `Zcash Protocol Specification, Version 2021.2.16. Section 8: Differences from the Zerocash paper `_ +.. [#halo2-arithmetization] `The halo2 Book: 1.2 PLONKish Arithmetization `_ +.. [#halo2-proving-system] `The halo2 Book: 3.1. Proving system `_ +.. [#orchard-keys] `The Orchard Book: 3.1. Keys and addresses `_ +.. [#orchard-actions] `The Orchard Book: 3.2. Actions `_ +.. [#orchard-commitments] `The Orchard Book: 3.3. Commitments `_ +.. [#orchard-tree] `The Orchard Book: 3.4. Commitment tree `_ +.. [#orchard-nullifiers] `The Orchard Book: 3.5. Nullifiers `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext `_ .. [#zip-0315] `ZIP 315: Best Practices for Wallet Handling of Multiple Pools `_ diff --git a/zip-0225.html b/zip-0225.html index a7325d8a..c2012802 100644 --- a/zip-0225.html +++ b/zip-0225.html @@ -21,10 +21,10 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/440>

    Terminology

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

    -

    The character § is used when referring to sections of the Zcash Protocol Specification 2.

    +

    The character § is used when referring to sections of the Zcash Protocol Specification 2.

    Abstract

    -

    This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol 2. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.

    +

    This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol 2. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.

    This ZIP also depends upon and defines modifications to the computation of the values TxId Digest, Signature Digest, and Authorizing Data Commitment defined by ZIP 244 7.

    Motivation

    @@ -474,11 +474,11 @@ Discussions-To: <https://g
    28
    - +
    - +
    2Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal]Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]
    @@ -486,7 +486,7 @@ Discussions-To: <    https://g 3 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions @@ -494,7 +494,7 @@ Discussions-To: <https://g 4 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions @@ -502,7 +502,7 @@ Discussions-To: <https://g 5 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.6: Action Descriptions + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.6: Action Descriptions diff --git a/zip-0225.rst b/zip-0225.rst index 1bb51827..be5f7fcd 100644 --- a/zip-0225.rst +++ b/zip-0225.rst @@ -21,13 +21,14 @@ The key words "MUST" and "MAY" in this document are to be interpreted as describ RFC 2119. [#RFC2119]_ The character § is used when referring to sections of the Zcash Protocol Specification -[#protocol-nu5]_. +[#protocol]_. + Abstract ======== This proposal defines an update to the Zcash peer-to-peer transaction format to include -support for data elements required to support the Orchard protocol [#protocol-nu5]_. +support for data elements required to support the Orchard protocol [#protocol]_. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements. @@ -261,6 +262,7 @@ Orchard Action Description (``OrchardAction``) The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification [#protocol-actiondesc]_. + Alternatives ============ @@ -307,6 +309,7 @@ The original definitions for the transaction fields that have been removed are: * The ``joinSplitPubKey`` and ``joinSplitSig`` fields were specified to be present if and only if :math:`\mathtt{nJoinSplit} > 0`. + Reference implementation ======================== @@ -317,10 +320,10 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-nu5] `Zcash Protocol Specification, Version 2021.1.24 or later [NU5 proposal] `_ -.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.4: Spend Descriptions `_ -.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.5: Output Descriptions `_ -.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 4.6: Action Descriptions `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] `_ +.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions `_ +.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions `_ +.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.6: Action Descriptions `_ .. [#zip-0222] `ZIP 222: Transparent Zcash Extensions `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ diff --git a/zip-0239.html b/zip-0239.html index d7532a2e..042dbfdc 100644 --- a/zip-0239.html +++ b/zip-0239.html @@ -18,10 +18,10 @@ Discussions-To: <https://g Pull-Request: <https://github.com/zcash/zips/pull/516>

    Terminology

    The key words "MUST", "MUST NOT", and "SHOULD" 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. 2

    -

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

    -

    The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in 4 for v5 and later transactions.

    -

    The term "authorizing data commitment" (denoted auth_digest), defined only for v5 and later transactions, is to be interpreted as described in 4.

    +

    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 term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in 6 for v5 and later transactions.

    +

    The term "authorizing data commitment" (denoted auth_digest), defined only for v5 and later transactions, is to be interpreted as described in 6.

    The term "witnessed transaction identifier" ("wtxid"), defined only for v5 and later transactions, is a 64-byte value given by concatenating the txid and the authorizing data commitment of the transaction.

    Abstract

    @@ -29,22 +29,22 @@ Pull-Request: <https://githu

    Motivation

    Historically, as in Bitcoin, the inv and getdata messages sent on the Zcash peer-to-peer network to announce or request transactions have referred to those transactions by txid.

    -

    Prior to the introduction of v5 transactions 3 in the NU5 network upgrade 5, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.

    -

    For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data 4. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.

    +

    Prior to the introduction of v5 transactions 5 in the NU5 network upgrade 7, a txid was always defined as the SHA-256d hash of the transaction data, the encoding of which is the same in block data and in the peer-to-peer protocol.

    +

    For v5 transactions, a new transaction digest algorithm is defined that constructs the txid from a tree of hashes, which include only effecting data 6. Witness data is committed to by a separate "authorizing data commitment". Unlike previous transaction versions, the format of serialized v5 transaction data is not consensus-critical.

    Not committing to the witness data in v5 transaction announcements would create inefficiencies: because a v5 transaction's witness can be malleated without altering the txid, a node in receipt of a v5 transaction that the node does not accept would generally still have to download that same transaction when announced by other peers. This is because the alternative — of not downloading a v5 transaction with a given txid after rejecting a previous transaction with that txid — would allow a third party to interfere with transaction relay by malleating a transaction's witness and announcing the resulting invalid transaction to nodes, preventing relay of the valid version of the transaction as well.

    This inefficiency was present in Bitcoin for almost 3 years after activation of its Segwit upgrade 8, until the adoption of BIP 339 9. The latter BIP specifies a way to use the Segwit "wtxid" (which commits to both effecting and witness data) in place of the txid when announcing and fetching transactions. In Zcash, the analogous identifier is also called the wtxid, but it encodes the pair (txid, auth_digest).

    This ZIP is modelled after BIP 339: it adds a MSG_WTX inv type to the peer-to-peer protocol, analogous to BIP 339's MSG_WTX inv type, that announces transactions by their wtxid. Note that the encoding and length of a Zcash wtxid is different to that of a Bitcoin wtxid.

    This ZIP does not introduce any equivalent of BIP 339's wtxidrelay message, since that is not needed for compatibility given that Zcash full nodes are required to support MSG_WTX based on the negotiated peer protocol version (see Deployment).

    Specification

    -

    A new inv type MSG_WTX (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value txid || auth_digest). This inv type MUST be used when announcing v5 transactions. The txid and auth_digest are as defined in 4.

    -

    In the case of getdata requests, the format of a v5 transaction obtained by a MSG_WTX inv type is as given in the Zcash protocol specification. 7

    +

    A new inv type MSG_WTX (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is the wtxid (i.e. the 64-byte value txid || auth_digest). This inv type MUST be used when announcing v5 transactions. The txid and auth_digest are as defined in 6.

    +

    In the case of getdata requests, the format of a v5 transaction obtained by a MSG_WTX inv type is as given in the Zcash protocol specification. 3

    An inv or getdata message MUST NOT use the MSG_WTX inv type for v4 or earlier transactions, or on peer connections that have not negotiated at least the peer protocol version specified in Deployment.

    Note that MSG_WTX might also be used for future transaction versions after v5. Since such versions are not currently consensus-valid, this is left unspecified for now.

    MSG_TX and MSG_WTX entries may be mixed in arbitrary order in an inv message or a getdata message. Since these entry types are of different lengths (36 bytes or 68 bytes respectively including the 4-byte type field), this implies that the size of the message is not determined by its initial count field, and has to be determined by parsing the whole message.

    Deployment

    This ZIP is assumed to be deployed in advance of the network upgrade that introduces v5 transactions, i.e. NU5. In 5, the minimum protocol version that signals support for NU5 on Testnet is defined to be 170014. Therefore, the peer protocol version that enables support for this specification is also defined to be 170014 (on both Testnet and Mainnet).

    -

    As specified in 2, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the MSG_WTX inv type until it has received the block preceding the NU5 network upgrade.

    +

    As specified in 4, a node that supports a network upgrade will clear its mempool when reaching the block before that upgrade's activation block. Before this point, the node will not accept transactions into its mempool that are invalid according to the pre-upgrade consensus protocol (so, in this case, it would not accept v5 transactions). This means that a correctly functioning node will not use the MSG_WTX inv type until it has received the block preceding the NU5 network upgrade.

    Nevertheless, it is possible for a node to receive an inv or getdata message with a MSG_WTX inv type, on a peer connection that has negotiated protocol version 170014 or later, before NU5 has activated. The node MUST handle this case in the same way that it would after NU5 activation when it has no v5 transactions to relay. Receiving a MSG_WTX inv type on a peer connection that has negotiated a protocol version before 170014, on the other hand, SHOULD be treated as a protocol error.

    As the MSG_WTX inv type is only enabled between peers that both support it, older clients remain fully compatible and interoperable before NU5 activates, or on a chain in which it does not activate.

    @@ -65,10 +65,26 @@ Pull-Request: <https://githu - +
    + + + +
    2Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet
    + + + + + + + +
    3Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus
    + + + + @@ -76,7 +92,7 @@ Pull-Request: <https://githu
    4 ZIP 200: Network Upgrade Mechanism
    - + @@ -84,32 +100,16 @@ Pull-Request: <https://githu
    35 ZIP 225: Version 5 Transaction Format
    - +
    46 ZIP 244: Transaction Identifier Non-Malleability
    - - - - - - -
    5ZIP 252: Deployment of the NU5 Network Upgrade
    - - - - - - - -
    6Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 3.12 Mainnet and Testnet
    - - +
    7Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 7.1: Transaction Encoding and ConsensusZIP 252: Deployment of the NU5 Network Upgrade
    diff --git a/zip-0239.rst b/zip-0239.rst index a82430e3..af909243 100644 --- a/zip-0239.rst +++ b/zip-0239.rst @@ -22,7 +22,7 @@ The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [#zip-0200]_ The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. The term "txid" means a transaction identifier, computed as a SHA-256d hash of the transaction data for v4 and earlier transactions, or as specified in [#zip-0244]_ @@ -98,7 +98,7 @@ when announcing v5 transactions. The ``txid`` and ``auth_digest`` are as defined In the case of ``getdata`` requests, the format of a v5 transaction obtained by a ``MSG_WTX`` inv type is as given in the Zcash protocol specification. -[#protocol-txnencodingandconsensus]_ +[#protocol-txnencoding]_ An ``inv`` or ``getdata`` message MUST NOT use the ``MSG_WTX`` inv type for v4 or earlier transactions, or on peer connections that have not negotiated at least @@ -166,12 +166,12 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12 Mainnet and Testnet `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0225] `ZIP 225: Version 5 Transaction Format `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 3.12 Mainnet and Testnet `_ -.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.2.2 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ .. [#bip-0141] `BIP 141: Segregated Witness (Consensus layer) `_ .. [#bip-0339] `BIP 339: WTXID-based transaction relay `_ .. [#p2p-inv] `Bitcoin Developer Reference: P2P Network — Inv `_ diff --git a/zip-0243.html b/zip-0243.html index 3cdb74a6..4b50f2b6 100644 --- a/zip-0243.html +++ b/zip-0243.html @@ -455,7 +455,7 @@ vJoinSplit: 00 2 -     Zcash Protocol Specification, version 2020.1.15 or later + Zcash Protocol Specification, version 2021.2.16 or later diff --git a/zip-0243.rst b/zip-0243.rst index 3d540dbc..25770ad7 100644 --- a/zip-0243.rst +++ b/zip-0243.rst @@ -527,7 +527,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, version 2020.1.15 or later `_ +.. [#protocol] `Zcash Protocol Specification, version 2021.2.16 or later `_ .. [#BLAKE2-personalization] `"BLAKE2: simpler, smaller, fast as MD5", Section 2.8 `_ .. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ diff --git a/zip-0244.html b/zip-0244.html index 265f0be4..c66de578 100644 --- a/zip-0244.html +++ b/zip-0244.html @@ -18,8 +18,8 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/411>

    Terminology

    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. 2

    -

    The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification 8.

    +

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

    +

    The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification 2.

    Abstract

    This proposal defines a new transaction digest algorithm for the NU5 network upgrade onward, in order to introduce non-malleable transaction identifiers that commit to all transaction data except for attestations to transaction validity.

    @@ -83,7 +83,7 @@ T.4: orchard_digest (32-byte hash output)

    The personalization field of this hash is set to:

    "ZcashTxHash_" || CONSENSUS_BRANCH_ID

    ZcashTxHash_ has 1 underscore character.

    -

    As in ZIP 143 5, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.

    +

    As in ZIP 143 6, CONSENSUS_BRANCH_ID is the 4-byte little-endian encoding of the consensus branch ID for the epoch of the block containing the transaction. Domain separation of the transaction id hash across parallel consensus branches provides replay protection: transactions targeted for one consensus branch will not have the same transaction identifier on other consensus branches.

    This signature hash personalization prefix has been changed to reflect the new role of this hash (relative to ZcashSigHash as specified in ZIP 143) as a transaction identifier rather than a commitment that is exclusively used for signature purposes. The previous computation of the transaction identifier was a SHA256d hash of the serialized transaction contents, and was not personalized.

    T.1: header_digest

    A BLAKE2b-256 hash of the following values

    @@ -127,7 +127,7 @@ T.2c: outputs_digest (32-byte hash)
    T.3: sapling_digest
    -

    In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the CompactBlock representation of Sapling data specified by the ZIP 307 Light Client Protocol 7.

    +

    In the case that Sapling spends or outputs are present, the digest of Sapling components is composed of two subtrees which are organized to permit easy interoperability with the CompactBlock representation of Sapling data specified by the ZIP 307 Light Client Protocol 8.

    This digest is a BLAKE2b-256 hash of the following values

    T.3a: sapling_spends_digest  (32-byte hash)
 T.3b: sapling_outputs_digest (32-byte hash)
@@ -169,7 +169,7 @@ T.3b.iii: sapling_outputs_noncompact_digest (32-byte hash)

    In the case that the transaction has Sapling spends but no Sapling outputs, sapling_outputs_digest is

    BLAKE2b-256("ZTxIdSOutputHash", [])
    T.3b.i: sapling_outputs_compact_digest -

    A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 7 CompactBlock format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:

    +

    A BLAKE2b-256 hash of the subset of Sapling output information included in the ZIP-307 8 CompactBlock format for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:

    T.3b.i.1: cmu                  (field encoding bytes)
 T.3b.i.2: ephemeral_key        (field encoding bytes)
 T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding)
    @@ -183,7 +183,7 @@ T.3b.i.3: enc_ciphertext[..52] (First 52 bytes of field encoding) 
    "ZTxIdSOutM__Hash" (2 underscore characters)
    T.3b.iii: sapling_outputs_noncompact_digest -

    A BLAKE2b-256 hash of the remaining subset of Sapling output information not included in the ZIP 307 7 CompactBlock format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:

    +

    A BLAKE2b-256 hash of the remaining subset of Sapling output information not included in the ZIP 307 8 CompactBlock format, excluding zkproof data, for all Sapling shielded outputs belonging to the transaction. For each output, the following elements are included in the hash:

    T.3b.iii.1: cv                    (field encoding bytes)
 T.3b.iii.2: enc_ciphertext[564..] (post-memo Poly1305 AEAD tag of field encoding)
 T.3b.iii.3: out_ciphertext        (field encoding bytes)
    @@ -203,7 +203,7 @@ T.4f: anchorOrchard (32 bytes) 
    BLAKE2b-256("ZTxIdOrchardHash", [])
    T.4a: orchard_actions_compact_digest -

    A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 7 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

    +

    A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 8 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

    T.4a.i  : nullifier            (field encoding bytes)
 T.4a.ii : cmx                  (field encoding bytes)
 T.4a.iii: ephemeralKey         (field encoding bytes)
@@ -218,7 +218,7 @@ T.4a.iv : encCiphertext[..52]  (First 52 bytes of field encoding)
    "ZTxIdOrcActMHash"
    T.4c: orchard_actions_noncompact_digest -

    A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 7 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

    +

    A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 8 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

    T.4c.i  : cv                    (field encoding bytes)
 T.4c.ii : rk                    (field encoding bytes)
 T.4c.iii: encCiphertext[564..]  (post-memo suffix of field encoding)
@@ -232,7 +232,7 @@ T.4c.iv : outCiphertext         (field encoding bytes)

    Signature Digest

    -

    A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 5 and ZIP 243 6. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.

    +

    A new per-input transaction digest algorithm is defined that constructs a hash that may be signed by a transaction creator to commit to the effects of the transaction. A signature digest is produced for each transparent input, each Sapling input, and each Orchard action. For transparent inputs, this follows closely the algorithms from ZIP 143 6 and ZIP 243 7. For shielded inputs, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.

    The overall structure of the hash is as follows; each name referenced here will be described in detail below:

    signature_digest
 ├── header_digest
@@ -254,7 +254,7 @@ S.4: orchard_digest         (32-byte hash output)
    S.2: transparent_sig_digest

    If we are producing a hash for the signature over a Sapling Spend or an Orchard Action, the value of transparent_sig_digest is identical to the value specified in section T.2.

    -

    If we are producing a hash for signature over a transparent input, the value of transparent_sig_digest depends upon the value of a hash_type flag as in ZIP 143 5.

    +

    If we are producing a hash for signature over a transparent input, the value of transparent_sig_digest depends upon the value of a hash_type flag as in ZIP 143 6.

    The construction of each component below depends upon the values of the hash_type flag bits. Each component will be described separately

    This digest is a BLAKE2b-256 hash of the following values

    S.2a: prevouts_sig_digest (32-byte hash)
@@ -365,7 +365,7 @@ A.3c: bindingSigOrchard        (field encoding bytes)
    is well-defined because \(\mathsf{tx\_count} > 0\) , due to the coinbase transaction in each block. Non-leaf hashes in this tree are BLAKE2b-256 hashes personalized by the string "ZcashAuthDatHash".

    -

    Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 3, is changed.

    +

    Changing the block header format to allow space for an additional commitment is somewhat invasive. Instead, the name and meaning of the hashLightClientRoot field, described in ZIP 221 4, is changed.

    hashLightClientRoot is renamed to hashBlockCommitments. The value of this hash is the BLAKE2b-256 hash personalized by the string "ZcashBlockCommit" of the following elements:

    hashLightClientRoot (as described in ZIP 221)
 hashAuthDataRoot    (as described below)
@@ -390,10 +390,18 @@ terminator          [0u8;32]
    - +
    + + + +
    2Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus
    + + + + @@ -401,7 +409,7 @@ terminator [0u8;32]
    3 ZIP 200: Network Upgrade Mechanism
    - + @@ -409,7 +417,7 @@ terminator [0u8;32]
    34 ZIP 221: FlyClient - Consensus Layer Changes
    - + @@ -417,7 +425,7 @@ terminator [0u8;32]
    45 ZIP 76: Transaction Signature Validation before Overwinter
    - + @@ -425,24 +433,16 @@ terminator [0u8;32]
    56 ZIP 143: Transaction Signature Validation for Overwinter
    - +
    67 ZIP 243: Transaction Signature Validation for Sapling
    - - - - - - -
    7ZIP 307: Light Client Protocol for Payment Detection
    - - +
    8Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and ConsensusZIP 307: Light Client Protocol for Payment Detection
    diff --git a/zip-0244.rst b/zip-0244.rst index 04c98cf4..a122db2e 100644 --- a/zip-0244.rst +++ b/zip-0244.rst @@ -10,6 +10,7 @@ License: MIT Discussions-To: + =========== Terminology =========== @@ -21,7 +22,7 @@ described in ZIP 200. [#zip-0200]_ The term "field encoding" refers to the binary serialized form of a Zcash transaction field, as specified in section 7.1 of the Zcash protocol specification -[#protocol-txnencodingandconsensus]_. +[#protocol-txnencoding]_. ======== Abstract @@ -86,7 +87,6 @@ Requirements is used to produce a signature hash in the case that the transaction contains no transparent inputs. - ================ Non-requirements ================ @@ -746,10 +746,10 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0221] `ZIP 221: FlyClient - Consensus Layer Changes `_ .. [#zip-0076] `ZIP 76: Transaction Signature Validation before Overwinter `_ .. [#zip-0143] `ZIP 143: Transaction Signature Validation for Overwinter `_ .. [#zip-0243] `ZIP 243: Transaction Signature Validation for Sapling `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ -.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ diff --git a/zip-0245.rst b/zip-0245.rst index ea5258c8..5748cc81 100644 --- a/zip-0245.rst +++ b/zip-0245.rst @@ -9,6 +9,7 @@ License: MIT Discussions-To: + Terminology =========== @@ -17,6 +18,7 @@ The key words "MUST" and "MUST NOT" in this document are to be interpreted as de The terms "consensus branch", "epoch", and "network upgrade" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_ + Abstract ======== @@ -24,6 +26,7 @@ This proposal defines changes to ZIP 244 [#zip-0244]_ transaction id and signatu algorithms to accommodate the inclusion of transparent Zcash extensions (TZEs) as defined in ZIP 222 [#zip-0222]_. + Specification ============= @@ -176,11 +179,13 @@ The personalization field of this hash is set to:: "ZTxAuthTZE__Hash" (2 underscore characters) + Reference implementation ======================== - https://github.com/zcash/librustzcash/pull/319/files + References ========== diff --git a/zip-0250.html b/zip-0250.html index c63d7f51..56f6e1ea 100644 --- a/zip-0250.html +++ b/zip-0250.html @@ -86,7 +86,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later diff --git a/zip-0250.rst b/zip-0250.rst index 8161b247..4615a370 100644 --- a/zip-0250.rst +++ b/zip-0250.rst @@ -128,7 +128,7 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0213] `ZIP 213: Shielded Coinbase `_ diff --git a/zip-0251.html b/zip-0251.html index c5702bd1..57235ebd 100644 --- a/zip-0251.html +++ b/zip-0251.html @@ -16,7 +16,7 @@ License: MIT

    Terminology

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

    The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 5

    -

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

    +

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

    "Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.

    Abstract

    @@ -65,7 +65,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728;

    Backward compatibility

    Prior to the network upgrade activating on each network, Canopy and pre-Canopy nodes are compatible and can connect to each other. However, Canopy nodes will have a preference for connecting to other Canopy nodes, so pre-Canopy nodes will gradually be disconnected in the run up to activation.

    Once the network upgrades, even though pre-Canopy nodes can still accept the numerically larger protocol version used by Canopy as being valid, Canopy nodes will always disconnect peers using lower protocol versions.

    -

    Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in 4; and use the same transaction digest algorithm as defined in 12. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. 12

    +

    Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 as defined in 4; and use the same transaction digest algorithm as defined in 12. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. 12

    Support in zcashd

    Support for Canopy on testnet will be implemented in zcashd version 3.1.0, which will advertise protocol version 170012. Support for Canopy on mainnet will be implemented in zcashd version 4.0.0, which will advertise protocol version 170013.

    @@ -83,7 +83,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later @@ -91,15 +91,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 3 - Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet - +
    - +
    4Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and ConsensusZcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus
    diff --git a/zip-0251.rst b/zip-0251.rst index 9b883a4a..ae162495 100644 --- a/zip-0251.rst +++ b/zip-0251.rst @@ -19,7 +19,7 @@ The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [#zip-0200]_ The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. "Canopy" is the code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4. @@ -110,7 +110,7 @@ will always disconnect peers using lower protocol versions. Unlike Overwinter and Sapling, and like Blossom and Heartwood, Canopy does not define a new transaction version. Canopy transactions are therefore in the same v4 format as Sapling transactions; use the same version group ID, i.e. 0x892F2085 -as defined in [#protocol-txnencodingandconsensus]_; and use the same transaction digest +as defined in [#protocol-txnencoding]_; and use the same transaction digest algorithm as defined in [#zip-0243]_. This does not imply that transactions are valid across the Canopy activation, since signatures MUST use the appropriate consensus branch ID. [#zip-0243]_ @@ -128,9 +128,9 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2020.1.15. Section 7.1: Transaction Encoding and Consensus `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16. Section 7.1: Transaction Encoding and Consensus `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ .. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter `_ .. [#zip-0207] `ZIP 207: Funding Streams `_ diff --git a/zip-0252.html b/zip-0252.html index b8411513..846fcef5 100644 --- a/zip-0252.html +++ b/zip-0252.html @@ -19,7 +19,7 @@ Pull-Request: <https://githu

    Terminology

    The key words "MUST" and "SHOULD" 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. 7

    -

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

    +

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

    Abstract

    This proposal defines the deployment of the NU5 network upgrade.

    @@ -120,7 +120,7 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 2 - Zcash Protocol Specification, Version 2021.1.24 or later + Zcash Protocol Specification, Version 2021.2.16 or later @@ -128,15 +128,15 @@ static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 1728; 3 - Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet - +
    - +
    4Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and ConsensusZcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus
    diff --git a/zip-0252.rst b/zip-0252.rst index 7802a5f7..c40204cc 100644 --- a/zip-0252.rst +++ b/zip-0252.rst @@ -22,7 +22,7 @@ The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [#zip-0200]_ The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. Abstract @@ -201,9 +201,9 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2021.1.24 or later `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 3.11: Mainnet and Testnet `_ -.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2021.1.24 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ .. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets `_ .. [#zip-0155] `ZIP 155: addrv2 message `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_ diff --git a/zip-1014.html b/zip-1014.html index 40bf2342..233a7524 100644 --- a/zip-1014.html +++ b/zip-1014.html @@ -27,13 +27,13 @@ Pull-Request: <https://githu

    Terminology

    The key words "MUST", "MUST NOT", "SHALL", "SHALL 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 6 and the Zcash Trademark Donation and License Agreement (4 or successor agreement).

    -

    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. 2

    +

    The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. 2

    "Electric Coin Company", also called "ECC", refers to the Zerocoin Electric Coin Company, LLC.

    "Bootstrap Project", also called "BP", refers to the 501(c)(3) nonprofit corporation of that name.

    "Zcash Foundation", also called "ZF", refers to the 501(c)(3) nonprofit corporation of that name.

    "Section 501(c)(3)" refers to that section of the U.S. Internal Revenue Code (Title 26 of the U.S. Code). 12

    "Community Advisory Panel" refers to the panel of community members assembled by the Zcash Foundation and described at 11.

    -

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

    +

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

    Abstract

    This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist of 20% of the block subsidies, split into 3 slices:

    @@ -154,7 +154,7 @@ Pull-Request: <https://githu 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.16 or later @@ -162,7 +162,7 @@ Pull-Request: <https://githu 3 - Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet + Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet diff --git a/zip-1014.rst b/zip-1014.rst index 6e9d8ae2..9ac81eac 100644 --- a/zip-1014.rst +++ b/zip-1014.rst @@ -31,7 +31,7 @@ described in ZIP 200 [#zip-0200]_ and the Zcash Trademark Donation and License Agreement ([#trademark]_ or successor agreement). 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. +as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. [#protocol]_ "Electric Coin Company", also called "ECC", refers to the Zerocoin Electric @@ -50,7 +50,7 @@ Code (Title 26 of the U.S. Code). [#section501c3]_ by the Zcash Foundation and described at [#zf-community]_. The terms "Testnet" and "Mainnet" are to be interpreted as described in -section 3.11 of the Zcash Protocol Specification [#protocol-networks]_. +section 3.12 of the Zcash Protocol Specification [#protocol-networks]_. Abstract @@ -94,6 +94,7 @@ contribute a slice of the block subsidies otherwise allocated to miners as a donation to support charitable, educational, and scientific activities within the meaning of Section 501(c)(3). + Requirements ============ @@ -399,8 +400,8 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2020.1.15 or later `_ -.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet `_ .. [#trademark] `Zcash Trademark Donation and License Agreement `_ .. [#osd] `The Open Source Definition `_ .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism `_