From 3d5f16a0a5b852e3c49a0b1cb5237b8cdd48d789 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 27 Jun 2021 14:09:22 +0100 Subject: [PATCH] ZIPs 212 and 213: updates for Orchard. Signed-off-by: Daira Hopwood --- index.html | 2 +- zip-0212.html | 296 ++++++++++++++++++++++++++++++++++++-------------- zip-0212.rst | 276 ++++++++++++++++++++++++++-------------------- zip-0213.html | 21 +++- zip-0213.rst | 22 +++- 5 files changed, 407 insertions(+), 210 deletions(-) diff --git a/index.html b/index.html index 345e8e6dc..25e54b908 100644 --- a/index.html +++ b/index.html @@ -67,7 +67,7 @@ 209 Prohibit Negative Shielded Chain Value Pool Balances Final 210 Sapling Anchor Deduplication within Transactions Withdrawn 211 Disabling Addition of New Value to the Sprout Chain Value Pool Implemented (zcashd) - 212 Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext Implemented (zcashd) + 212 Allow Recipient to Derive Ephemeral Secret from Note Plaintext Implemented (zcashd) 213 Shielded Coinbase Final 214 Consensus rules for a Zcash Development Fund Implemented (zcashd) 215 Explicitly Defining and Modifying Ed25519 Validation Rules Implemented (zcashd) diff --git a/zip-0212.html b/zip-0212.html index 29cba4dfa..0d452df63 100644 --- a/zip-0212.html +++ b/zip-0212.html @@ -1,14 +1,14 @@ - ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext + ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext 
ZIP: 212
-Title: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext
+Title: Allow Recipient to Derive Ephemeral Secret from Note Plaintext
 Owners: Sean Bowe <sean@electriccoin.co>
 Status: Implemented (zcashd)
 Category: Consensus
@@ -16,15 +16,43 @@
 License: MIT

Terminology

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

-

The function - \(\mathsf{ToScalar}\) - is defined as in Section 4.4.2 of the Zcash Protocol Specification. 2

+

The following functions are defined in the Zcash Protocol Specification 2 according to the type (Sapling or Orchard) of note plaintext being processed:

+
    +
  • let + \(\mathsf{ToScalar}\) + be + \(\mathsf{ToScalar^{Sapling}}\) + defined in section 4.2.2 5 or + \(\mathsf{ToScalar^{Orchard}}\) + defined in section 4.2.3 6;
    • +
  • let + \(\mathsf{DiversifyHash}\) + be + \(\mathsf{DiversifyHash^{Sapling}}\) + or + \(\mathsf{DiversifyHash^{Orchard}}\) + defined in section 5.4.1.6 12;
    • +
  • let + \(\mathsf{KA}\) + be + \(\mathsf{KA^{Sapling}}\) + defined in section 5.4.5.3 13 or + \(\mathsf{KA^{Orchard}}\) + defined in section 5.4.5.5 14;
    • +
  • let + \(\mathsf{NoteCommit}\) + be + \(\mathsf{NoteCommit^{Sapling}}\) + or + \(\mathsf{NoteCommit^{Orchard}}\) + defined in section 4.1.8 4.
    • +

Abstract

-

This ZIP proposes a new note plaintext format for Sapling Outputs in transactions. The new format allows recipients to check the well-formedness of the ephemeral Diffie-Hellman key in the Output to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.

+

This ZIP proposes a new note plaintext format for Sapling Outputs (later extended to include Orchard Actions) in transactions. The new format allows recipients to verify that the sender of an Output or Action knows the private key corresponding to the ephemeral Diffie-Hellman key, in order to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.

Motivation

-

The Sapling payment protocol contains a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.

+

The Sapling and Orchard payment protocols have a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.

The feature works by allowing payment addresses to become a tuple \((\mathsf{pk_d}, \mathsf{d})\) of a public key @@ -34,46 +62,48 @@ -bit diversifier \(\mathsf{d}\) such that - \(\mathsf{pk_d} = [\mathsf{ivk}] GH(\mathsf{d})\) + \(\mathsf{pk_d} = [\mathsf{ivk}]\, \mathsf{DiversifyHash}(\mathsf{d})\) for some incoming viewing key \(\mathsf{ivk}\) . The hash function - \(GH(\mathsf{d})\) - maps from a diversifier to prime order elements of the Jubjub elliptic curve. It is possible for a user to choose many + \(\mathsf{DiversifyHash}(\mathsf{d})\) + maps from a diversifier to prime-order elements of the Jubjub or Pallas elliptic curve. It is possible for a user to choose many \(\mathsf{d}\) to create several distinct and unlinkable payment addresses of this form.

-

In order to make a payment to a Sapling address, an ephemeral secret +

In order to make a payment to a Sapling or Orchard address, an ephemeral secret \(\mathsf{esk}\) is sampled by the sender and an ephemeral public key - \(\mathsf{epk} = [\mathsf{esk}] GH(\mathsf{d})\) - is included in the Output description. Then, a shared Diffie-Hellman secret is computed by the sender as - \([\mathsf{esk}] [8] \mathsf{pk_d}\) + \(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{DiversifyHash}(\mathsf{d})\) + is included in the Output or Action description. Then, a shared Diffie-Hellman secret is computed by the sender as + \(\mathsf{KA.Agree}(\mathsf{esk}, \mathsf{pk_d})\) . The recipient can recover this shared secret without knowledge of the particular \(\mathsf{d}\) by computing - \([\mathsf{ivk}] [8] \mathsf{epk}\) + \(\mathsf{KA.Agree}(\mathsf{ivk}, \mathsf{epk})\) . This shared secret is then used as part of note decryption.

-

Naively, the recipient cannot know which +

Naïvely, the recipient cannot know which \((\mathsf{pk_d}, \mathsf{d})\) was used to compute the shared secret, but the sender is asked to include the \(\mathsf{d}\) within the note plaintext to reconstruct the note. However, if the recipient has more than one known address, an attacker could use a different payment address to perform secret exchange and, by observing the behavior of the recipient, link the two diversified addresses together. (This attacker strategy was discovered by Brian Warner earlier in the design of the Sapling protocol.)

-

In order to prevent this attack, the protocol currently forces the sender to prove knowledge of the discrete logarithm of +

In order to prevent this attack, before activation of this ZIP the protocol forced the sender to prove knowledge of the discrete logarithm of \(\mathsf{epk}\) with respect to the - \(\mathsf{g_d} = GH(\mathsf{d})\) + \(\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})\) included within the note commitment. This \(\mathsf{g_d}\) is determined by \(\mathsf{d}\) - and recomputed during note decryption, and so the recipient will either be unable to decrypt the note or the sender will be unable to perform the attack.

-

However, this check occurs as part of the zero-knowledge proof statement and so relies on the soundness of the underlying zk-SNARK in Sapling, and therefore it relies on relatively strong cryptographic assumptions and a trusted setup. It would be preferable to force the sender to transfer sufficient information in the note plaintext to allow deriving + and recomputed during note decryption, and so either the note decryption will fail, or the sender will be unable to produce the proof that requires knowledge of the discrete logarithm.

+

However, the latter proof was part of the Sapling Output statement, and so relied on the soundness of the underlying Groth16 zk-SNARK — hence on relatively strong cryptographic assumptions and a trusted setup. It is preferable to force the sender to transfer sufficient information in the note plaintext to allow deriving \(\mathsf{esk}\) , so that, during note decryption, the recipient can check that - \(\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}\) - (for the expected + \(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\) + for the expected \(\mathsf{g_d}\) - ) and ignore the payment as invalid otherwise. This forms a line of defense in the case that soundness of the zk-SNARK does not hold.

+ , and ignore the payment as invalid otherwise. For Sapling, this forms a line of defense in the case that soundness of the zk-SNARK does not hold. For Orchard, this check is essential because (for efficiency and simplicity) + \(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\) + is not checked in the Action statement.

Merely sending \(\mathsf{esk}\) to the recipient in the note plaintext would require us to enlarge the note plaintext, but also would compromise the proof of IND-CCA2 security for in-band secret distribution. We avoid both of these concerns by using a key derivation to obtain both @@ -83,26 +113,26 @@ .

Specification

-

The specification in this ZIP is intended to be aligned with version 2020.1.15 of the Zcash Protocol Specification 2. See the Change History of that document for relevant corrections.

-

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

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 \(\mathsf{PRF^{expand}}\) for the purposes of this ZIP. This function is keyed by a 256-bit key \(\mathsf{sk}\) and takes an arbitrary length byte sequence as input, returning a \(64\) -byte sequence as output.

-

Changes to Sapling Note plaintexts

-

Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification 5. Currently, the encoding of a Sapling note plaintext requires that the first byte take the form - \(\textbf{0x01}\) +

Changes to Sapling and Orchard Note plaintexts

+

Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification 15. Before activation of this ZIP, the encoding of a Sapling note plaintext required that the first byte take the form + \(\mathtt{0x01}\) , indicating the version of the note plaintext. In addition, a \(256\) -bit \(\mathsf{rcm}\) field exists within the note plaintext and encoding.

-

Following the activation of this ZIP, senders of Sapling notes MUST use the following new note plaintext format:

+

Following the activation of this ZIP, senders of Sapling or Orchard notes MUST use the following note plaintext format:

  • The first byte of the encoding MUST take the form - \(\textbf{0x02}\) + \(\mathtt{0x02}\) (representing the new note plaintext version).
  • The field \(\mathsf{rcm}\) @@ -110,24 +140,22 @@ \(\mathsf{rseed}\) . This field \(\mathsf{rseed}\) - of the Sapling note plaintext no longer takes the type of - \(\mathsf{NoteCommit^{Sapling}.Trapdoor}\) - but instead is a + of the Sapling or Orchard note plaintext no longer takes the type of + \(\mathsf{NoteCommit.Trapdoor}\) + (as it did for Sapling) but instead is a \(32\) -byte sequence.
-

The requirement that - \(\mathsf{rseed}\) - (previously, +

The requirement that the former \(\mathsf{rcm}\) - ) be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from the description of note plaintexts in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. 6 7

+ field be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from descriptions of note plaintexts in the Zcash Protocol Specification.

-

Changes to the process of sending Sapling notes

-

The process of sending notes in Sapling is described in section 4.6.2 of the Zcash Protocol Specification 8. During this process, the sender samples +

Changes to the process of sending Sapling or Orchard notes

+

The process of sending notes is described in section 4.7.2 of the Zcash Protocol Specification for Sapling 7 and section 4.7.3 for Orchard 8. In addition, the process of encrypting a note is described (currently) in section 4.19.1 of the Zcash Protocol Specification 9. Prior to activation of this ZIP, the sender sampled \(\mathsf{rcm^{new}}\) - uniformly at random. In addition, the process of encrypting a note is described in section 4.17.1 of the Zcash Protocol Specification 3. During this process, the sender also samples the ephemeral private key + and the ephemeral private key \(\mathsf{esk}\) - uniformly at random.

+ uniformly at random during this process.

After the activation of this ZIP, the sender MUST instead sample a uniformly random \(32\) -byte sequence @@ -137,30 +165,46 @@ in place of \(\mathsf{rcm^{new}}\) .

-

- \(\mathsf{rcm^{new}}\) - MUST be computed by the sender as the output of - \(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\) - .

-

- \(\mathsf{esk}\) - MUST be computed by the sender as the output of - \(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\) - .

+

For Sapling:

+
    +
  • + \(\mathsf{rcm^{new}}\) + MUST be computed by the sender as the output of + \(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\) + .
    • +
  • + \(\mathsf{esk}\) + MUST be computed by the sender as the output of + \(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\) + .
    • +
+

For Orchard, an encoding of ρ is appended to these PRF inputs, as specified in section 4.7.3 of the Zcash Protocol Specification 8.

-

Changes to the process of receiving Sapling notes

-

The process of receiving notes in Sapling is described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. 6 7

-

There is a "grace period" of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte 0x01 MUST still be accepted.

+

Changes to the process of receiving Sapling or Orchard notes

+

The process of receiving notes in Sapling is described in sections 4.19.2 and 4.19.3 of the Zcash Protocol Specification. 10 11

+

There is a "grace period" of 32256 blocks starting from the block at which this ZIP activates, during which note plaintexts with lead byte + \(\mathtt{0x01}\) + MUST still be accepted.

Let ActivationHeight be the activation height of this ZIP, and let GracePeriodEndHeight be ActivationHeight + 32256.

The height of a transaction in a mined block is defined as the height of that block. An implementation MAY also decrypt mempool transactions, in which case the height used is the height of the next block at the time of the check. An implementation SHOULD NOT attempt to decrypt mempool transactions without having obtained a best-effort view of the current block chain height.

When the recipient of a note (either using an incoming viewing key or a full viewing key) is able to decrypt a note plaintext, it performs the following check on the plaintext lead byte, based on the height of the containing transaction:

    -
  • If the height is less than ActivationHeight, then only 0x01 is accepted as the plaintext lead byte.
    • -
  • If the height is at least ActivationHeight and less than GracePeriodEndHeight, then either 0x01 or 0x02 is accepted as the plaintext lead byte.
    • -
  • If the height is at least GracePeriodEndHeight, then only 0x02 is accepted as the plaintext lead byte.
    • +
  • If the height is less than ActivationHeight, then only + \(\mathtt{0x01}\) + is accepted as the plaintext lead byte.
    • +
  • If the height is at least ActivationHeight and less than GracePeriodEndHeight, then either + \(\mathtt{0x01}\) + or + \(\mathtt{0x02}\) + is accepted as the plaintext lead byte.
    • +
  • If the height is at least GracePeriodEndHeight, then only + \(\mathtt{0x02}\) + is accepted as the plaintext lead byte.

If the plaintext lead byte is not accepted then the note MUST be discarded. However, if an implementation decrypted the note from a mempool transaction and it was accepted at that time, but it is later mined in a block after the end of the grace period, then it MAY be retained.

-

A note plaintext with lead byte 0x02 contains a field +

A note plaintext with lead byte + \(\mathtt{0x02}\) + contains a field \(\mathsf{rseed}\) that is a \(32\) @@ -170,17 +214,22 @@ \(\mathsf{rcm}\) as the output of \(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\) - . Further, the recipient MUST compute + in the case of Sapling. Further, the recipient MUST compute \(\mathsf{esk}\) as \(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\) - and check that - \(\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}\) - and fail decryption if this check is not satisfied.

+ in the case of Sapling, and check that + \(\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}\) + , failing decryption if this check is not satisfied. For Orchard, an encoding of ρ is appended to the PRF inputs, as for encryption.

Consensus rule change for coinbase transactions

-

After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in 10, MUST have note plaintext lead byte equal to 0x02.

-

This applies even during the “grace period”, and also applies to funding stream outputs 9 sent to shielded payment addresses, if there are any.

+

After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in 17, MUST have note plaintext lead byte equal to + \(\mathtt{0x02}\) + .

+

This applies even during the “grace period”, and also applies to funding stream outputs 16 sent to shielded payment addresses, if there are any.

+

Since NU5 activates after the end of the grace period 19, Orchard outputs will always require a note plaintext lead byte equal to + \(\mathtt{0x02}\) + .

Rationale

@@ -197,18 +246,25 @@ itself, but this appears to be an unnecessary complication and is likely slower than just supplying \(\mathsf{esk}\) .

-

The grace period is intended to mitigate loss-of-funds risk due to non-conformant sending wallet implementations. The intention is that during the grace period (of about 4 weeks), it will be possible to identify wallets that are still sending plaintexts according to the old specification, and cajole their developers to make the required updates. For the avoidance of doubt, such wallets are non-conformant because it is a "MUST" requirement to immediately switch to sending note plaintexts with lead byte 0x02 (and the other changes in this specification) at the upgrade. Note that nodes will clear their mempools when the upgrade activates, which will clear all plaintexts with lead byte 0x01 that were sent conformantly and not mined before the upgrade.

+

The grace period is intended to mitigate loss-of-funds risk due to non-conformant sending wallet implementations. The intention is that during the grace period (of about 4 weeks), it will be possible to identify wallets that are still sending plaintexts according to the old specification, and cajole their developers to make the required updates. For the avoidance of doubt, such wallets are non-conformant because it is a "MUST" requirement to immediately switch to sending note plaintexts with lead byte + \(\mathtt{0x02}\) + (and the other changes in this specification) at the upgrade. Note that nodes will clear their mempools when the upgrade activates, which will clear all plaintexts with lead byte + \(\mathtt{0x01}\) + that were sent conformantly and not mined before the upgrade.

+

Historical note: in practice some note plaintexts with lead byte + \(\mathtt{0x01}\) + were non-conformantly sent even after the end of the specified grace period. ZecWallet extended its implementation of the grace period by a further 161280 blocks (approximately 20 weeks) in order to allow for recovery of these funds 20.

Security and Privacy Considerations

-

The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform a linkability attack trivially in that case.

-

In the naive case where the protocol is modified so that +

The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub (or Pallas) elliptic curve, for it could perform a linkability attack trivially in that case.

+

In the naïve case where the protocol is modified so that \(\mathsf{esk}\) is supplied directly to the recipient (rather than derived through \(\mathsf{rseed}\) ) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.

Deployment

-

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

+

This proposal will be deployed with the Canopy network upgrade. 18

Reference Implementation

In zcashd:

@@ -236,62 +292,118 @@ 2 - Zcash Protocol Specification, Version 2020.1.15 or later + Zcash Protocol Specification, Version 2021.2.6 or later - +
- +
3Zcash Protocol Specification, Version 2020.1.15. Section 4.17.1: Encryption (Sapling)Zcash Protocol Specification, Version 2021.2.6. Section 4.1.2: Pseudo Random Functions
- +
- +
4Zcash Protocol Specification, Version 2020.1.15. Section 4.1.2: Pseudo Random FunctionsZcash Protocol Specification, Version 2021.2.6. Section 4.1.8: Commitment
- +
- +
5Zcash Protocol Specification, Version 2020.1.15. Section 5.5: Encodings of Note Plaintexts and Memo FieldsZcash Protocol Specification, Version 2021.2.6. Section 4.2.2: Sapling Key Components
- +
- +
6Zcash Protocol Specification, Version 2020.1.15. Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling)Zcash Protocol Specification, Version 2021.2.6. Section 4.2.3: Orchard Key Components
- +
- +
7Zcash Protocol Specification, Version 2020.1.15. Section 4.17.3: Decryption using a Full Viewing Key (Sapling)Zcash Protocol Specification, Version 2021.2.6. Section 4.7.2: Sending Notes (Sapling)
- +
- +
8Zcash Protocol Specification, Version 2020.1.15. Section 4.6.2: Sending Notes (Sapling)Zcash Protocol Specification, Version 2021.2.6. Section 4.7.3: Sending Notes (Orchard)
- +
+ + + +
9Zcash Protocol Specification, Version 2021.2.6. Section 4.19.1: Encryption (Sapling and Orchard)
+ + + + + + + +
10Zcash Protocol Specification, Version 2021.2.6. Section 4.19.2: Decryption using an Incoming Viewing Key (Sapling and Orchard)
+ + + + + + + +
11Zcash Protocol Specification, Version 2021.2.6. Section 4.19.3: Decryption using a Full Viewing Key (Sapling and Orchard)
+ + + + + + + +
12Zcash Protocol Specification, Version 2021.2.6. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions
+ + + + + + + +
13Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.3 Sapling Key Agreement
+ + + + + + + +
14Zcash Protocol Specification, Version 2021.2.6. Section 5.4.5.5 Orchard Key Agreement
+ + + + + + + +
15Zcash Protocol Specification, Version 2021.2.6. Section 5.5: Encodings of Note Plaintexts and Memo Fields
+ + + + @@ -299,7 +411,7 @@
16 ZIP 207: Split Founders' Reward
- + @@ -307,11 +419,27 @@
1017 ZIP 213: Shielded Coinbase
- +
1118 ZIP 251: Deployment of the Canopy Network Upgrade
+ + + + + + + +
19ZIP 252: Deployment of the NU5 Network Upgrade
+ + + + + + + +
20Commit c31a04a in aditypk00/librustzcash: Move ZIP-212 grace period to end of April
diff --git a/zip-0212.rst b/zip-0212.rst index 59da6e5a6..88f29bdde 100644 --- a/zip-0212.rst +++ b/zip-0212.rst @@ -1,7 +1,7 @@ :: ZIP: 212 - Title: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext + Title: Allow Recipient to Derive Ephemeral Secret from Note Plaintext Owners: Sean Bowe Status: Implemented (zcashd) Category: Consensus @@ -15,47 +15,64 @@ Terminology The key words "MUST", "MUST NOT", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ -The function :math:`\mathsf{ToScalar}` is defined as in Section 4.4.2 of the -Zcash Protocol Specification. [#protocol]_ +The following functions are defined in the Zcash Protocol Specification [#protocol]_ +according to the type (Sapling or Orchard) of note plaintext being processed: + +* let :math:`\mathsf{ToScalar}` be + :math:`\mathsf{ToScalar^{Sapling}}` defined in section 4.2.2 [#protocol-saplingkeycomponents]_ or + :math:`\mathsf{ToScalar^{Orchard}}` defined in section 4.2.3 [#protocol-orchardkeycomponents]_; +* let :math:`\mathsf{DiversifyHash}` be + :math:`\mathsf{DiversifyHash^{Sapling}}` or :math:`\mathsf{DiversifyHash^{Orchard}}` + defined in section 5.4.1.6 [#protocol-concretediversifyhash]_; +* let :math:`\mathsf{KA}` be + :math:`\mathsf{KA^{Sapling}}` defined in section 5.4.5.3 [#protocol-concretesaplingkeyagreement]_ or + :math:`\mathsf{KA^{Orchard}}` defined in section 5.4.5.5 [#protocol-concreteorchardkeyagreement]_; +* let :math:`\mathsf{NoteCommit}` be + :math:`\mathsf{NoteCommit^{Sapling}}` or :math:`\mathsf{NoteCommit^{Orchard}}` + defined in section 4.1.8 [#protocol-abstractcommit]_. Abstract ======== -This ZIP proposes a new note plaintext format for Sapling Outputs in -transactions. The new format allows recipients to check the well-formedness of -the ephemeral Diffie-Hellman key in the Output to avoid an assumption on -zk-SNARK soundness for preventing diversified address linkability. +This ZIP proposes a new note plaintext format for Sapling Outputs (later +extended to include Orchard Actions) in transactions. The new format allows +recipients to verify that the sender of an Output or Action knows the +private key corresponding to the ephemeral Diffie-Hellman key, in order to +avoid an assumption on zk-SNARK soundness for preventing diversified address +linkability. Motivation ========== -The Sapling payment protocol contains a feature called "diversified addresses" -which allows a single incoming viewing key to receive payments on an enormous -number of distinct and unlinkable payment addresses. This feature allows users -to maintain many payment addresses without paying additional overhead during -blockchain scanning. +The Sapling and Orchard payment protocols have a feature called "diversified +addresses" which allows a single incoming viewing key to receive payments on +an enormous number of distinct and unlinkable payment addresses. This feature +allows users to maintain many payment addresses without paying additional +overhead during blockchain scanning. The feature works by allowing payment addresses to become a tuple :math:`(\mathsf{pk_d}, \mathsf{d})` of a public key :math:`\mathsf{pk_d}` and :math:`88`-bit diversifier :math:`\mathsf{d}` such that -:math:`\mathsf{pk_d} = [\mathsf{ivk}] GH(\mathsf{d})` for some incoming viewing key -:math:`\mathsf{ivk}`. The hash function :math:`GH(\mathsf{d})` maps from a -diversifier to prime order elements of the Jubjub elliptic curve. It -is possible for a user to choose many :math:`\mathsf{d}` to create several -distinct and unlinkable payment addresses of this form. - -In order to make a payment to a Sapling address, an ephemeral secret +:math:`\mathsf{pk_d} = [\mathsf{ivk}]\, \mathsf{DiversifyHash}(\mathsf{d})` for +some incoming viewing key :math:`\mathsf{ivk}`. The hash function +:math:`\mathsf{DiversifyHash}(\mathsf{d})` maps from a diversifier to prime-order +elements of the Jubjub or Pallas elliptic curve. It is possible for a user +to choose many :math:`\mathsf{d}` to create several distinct and unlinkable +payment addresses of this form. + +In order to make a payment to a Sapling or Orchard address, an ephemeral secret :math:`\mathsf{esk}` is sampled by the sender and an ephemeral public key -:math:`\mathsf{epk} = [\mathsf{esk}] GH(\mathsf{d})` is included in the -Output description. Then, a shared Diffie-Hellman secret is computed by the -sender as :math:`[\mathsf{esk}] [8] \mathsf{pk_d}`. The recipient can recover -this shared secret without knowledge of the particular :math:`\mathsf{d}` by -computing :math:`[\mathsf{ivk}] [8] \mathsf{epk}`. This shared secret is then -used as part of note decryption. - -Naively, the recipient cannot know which :math:`(\mathsf{pk_d}, \mathsf{d})` +:math:`\mathsf{epk} = [\mathsf{esk}]\, \mathsf{DiversifyHash}(\mathsf{d})` is +included in the Output or Action description. Then, a shared Diffie-Hellman +secret is computed by the sender as +:math:`\mathsf{KA.Agree}(\mathsf{esk}, \mathsf{pk_d})`. The recipient can +recover this shared secret without knowledge of the particular :math:`\mathsf{d}` +by computing :math:`\mathsf{KA.Agree}(\mathsf{ivk}, \mathsf{epk})`. This shared +secret is then used as part of note decryption. + +Naïvely, the recipient cannot know which :math:`(\mathsf{pk_d}, \mathsf{d})` was used to compute the shared secret, but the sender is asked to include the :math:`\mathsf{d}` within the note plaintext to reconstruct the note. However, if the recipient has more than one known address, an attacker could use a @@ -64,22 +81,26 @@ behavior of the recipient, link the two diversified addresses together. (This attacker strategy was discovered by Brian Warner earlier in the design of the Sapling protocol.) -In order to prevent this attack, the protocol currently forces the sender to -prove knowledge of the discrete logarithm of :math:`\mathsf{epk}` with respect -to the :math:`\mathsf{g_d} = GH(\mathsf{d})` included within the note -commitment. This :math:`\mathsf{g_d}` is determined by :math:`\mathsf{d}` -and recomputed during note decryption, and so the recipient will either be -unable to decrypt the note or the sender will be unable to perform the attack. - -However, this check occurs as part of the zero-knowledge proof statement and so -relies on the soundness of the underlying zk-SNARK in Sapling, and therefore it -relies on relatively strong cryptographic assumptions and a trusted setup. It -would be preferable to force the sender to transfer sufficient information in -the note plaintext to allow deriving :math:`\mathsf{esk}`, so that, during note -decryption, the recipient can check that :math:`\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}` -(for the expected :math:`\mathsf{g_d}`) and ignore the payment as invalid -otherwise. This forms a line of defense in the case that soundness of the -zk-SNARK does not hold. +In order to prevent this attack, before activation of this ZIP the protocol +forced the sender to prove knowledge of the discrete logarithm of +:math:`\mathsf{epk}` with respect to the +:math:`\mathsf{g_d} = \mathsf{DiversifyHash}(\mathsf{d})` included within the +note commitment. This :math:`\mathsf{g_d}` is determined by :math:`\mathsf{d}` +and recomputed during note decryption, and so either the note decryption will +fail, or the sender will be unable to produce the proof that requires knowledge +of the discrete logarithm. + +However, the latter proof was part of the Sapling Output statement, and so +relied on the soundness of the underlying Groth16 zk-SNARK — hence on relatively +strong cryptographic assumptions and a trusted setup. It is preferable to force +the sender to transfer sufficient information in the note plaintext to allow +deriving :math:`\mathsf{esk}`, so that, during note decryption, the recipient +can check that :math:`\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}` for the +expected :math:`\mathsf{g_d}`, and ignore the payment as invalid otherwise. +For Sapling, this forms a line of defense in the case that soundness of the +zk-SNARK does not hold. For Orchard, this check is essential because (for +efficiency and simplicity) :math:`\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}` +is *not* checked in the Action statement. Merely sending :math:`\mathsf{esk}` to the recipient in the note plaintext would require us to enlarge the note plaintext, but also would compromise the proof @@ -91,9 +112,8 @@ 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 2020.1.15 -of the Zcash Protocol Specification [#protocol]_. See the Change History of -that document for relevant corrections. +The specification in this ZIP is intended to be aligned with version 2021.2.6 +or later of the Zcash Protocol Specification [#protocol]_. Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification [#protocol-abstractprfs]_. We will be adapting @@ -101,61 +121,66 @@ Protocol Specification [#protocol-abstractprfs]_. We will be adapting keyed by a 256-bit key :math:`\mathsf{sk}` and takes an arbitrary length byte sequence as input, returning a :math:`64`-byte sequence as output. -Changes to Sapling Note plaintexts ----------------------------------- +Changes to Sapling and Orchard Note plaintexts +---------------------------------------------- Note plaintext encodings are specified in section 5.5 of the Zcash Protocol -Specification [#protocol-notept]_. Currently, the encoding of a Sapling note plaintext -requires that the first byte take the form :math:`\textbf{0x01}`, indicating -the version of the note plaintext. In addition, a :math:`256`-bit -:math:`\mathsf{rcm}` field exists within the note plaintext and encoding. +Specification [#protocol-notept]_. Before activation of this ZIP, the encoding +of a Sapling note plaintext required that the first byte take the form +:math:`\mathtt{0x01}`, indicating the version of the note plaintext. In +addition, a :math:`256`-bit :math:`\mathsf{rcm}` field exists within the +note plaintext and encoding. -Following the activation of this ZIP, senders of Sapling notes MUST use -the following new note plaintext format: +Following the activation of this ZIP, senders of Sapling or Orchard notes +MUST use the following note plaintext format: -* The first byte of the encoding MUST take the form :math:`\textbf{0x02}` +* The first byte of the encoding MUST take the form :math:`\mathtt{0x02}` (representing the new note plaintext version). * The field :math:`\mathsf{rcm}` of the encoding is renamed to - :math:`\mathsf{rseed}`. This field :math:`\mathsf{rseed}` of the Sapling note - plaintext no longer takes the type of :math:`\mathsf{NoteCommit^{Sapling}.Trapdoor}` - but instead is a :math:`32`-byte sequence. - -The requirement that :math:`\mathsf{rseed}` (previously, :math:`\mathsf{rcm}`) -be a scalar of the Jubjub elliptic curve, when interpreted as a little endian -integer, is removed from the description of note plaintexts in sections 4.17.2 -and 4.17.3 of the Zcash Protocol Specification. [#protocol-saplingdecryptivk]_ -[#protocol-saplingdecryptovk]_ - -Changes to the process of sending Sapling notes ------------------------------------------------ - -The process of sending notes in Sapling is described in section 4.6.2 of the -Zcash Protocol Specification [#protocol-saplingsend]_. During this process, the -sender samples :math:`\mathsf{rcm^{new}}` uniformly at random. In addition, the -process of encrypting a note is described in section 4.17.1 of the Zcash Protocol -Specification [#protocol-saplingencrypt]_. During this process, the sender also -samples the ephemeral private key :math:`\mathsf{esk}` uniformly at random. + :math:`\mathsf{rseed}`. This field :math:`\mathsf{rseed}` of the Sapling + or Orchard note plaintext no longer takes the type of + :math:`\mathsf{NoteCommit.Trapdoor}` (as it did for Sapling) but instead + is a :math:`32`-byte sequence. + +The requirement that the former :math:`\mathsf{rcm}` field be a scalar of the +Jubjub elliptic curve, when interpreted as a little endian integer, is removed +from descriptions of note plaintexts in the Zcash Protocol Specification. + +Changes to the process of sending Sapling or Orchard notes +---------------------------------------------------------- + +The process of sending notes is described in section 4.7.2 of the Zcash +Protocol Specification for Sapling [#protocol-saplingsend]_ and section 4.7.3 +for Orchard [#protocol-orchardsend]_. In addition, the process of encrypting +a note is described (currently) in section 4.19.1 of the Zcash Protocol +Specification [#protocol-saplingandorchardencrypt]_. Prior to activation of +this ZIP, the sender sampled :math:`\mathsf{rcm^{new}}` and the ephemeral +private key :math:`\mathsf{esk}` uniformly at random during this process. After the activation of this ZIP, the sender MUST instead sample a uniformly random :math:`32`-byte sequence :math:`\mathsf{rseed}`. The note plaintext takes :math:`\mathsf{rseed}` in place of :math:`\mathsf{rcm^{new}}`. -:math:`\mathsf{rcm^{new}}` MUST be computed by the sender as the output of -:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))`. +For Sapling: + +* :math:`\mathsf{rcm^{new}}` MUST be computed by the sender as the output of + :math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))`. +* :math:`\mathsf{esk}` MUST be computed by the sender as the output of + :math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))`. -:math:`\mathsf{esk}` MUST be computed by the sender as the output of -:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))`. +For Orchard, an encoding of ρ is appended to these PRF inputs, as specified in +section 4.7.3 of the Zcash Protocol Specification [#protocol-orchardsend]_. -Changes to the process of receiving Sapling notes -------------------------------------------------- +Changes to the process of receiving Sapling or Orchard notes +------------------------------------------------------------ -The process of receiving notes in Sapling is described in sections 4.17.2 and -4.17.3 of the Zcash Protocol Specification. [#protocol-saplingdecryptivk]_ -[#protocol-saplingdecryptovk]_ +The process of receiving notes in Sapling is described in sections 4.19.2 and +4.19.3 of the Zcash Protocol Specification. [#protocol-decryptivk]_ +[#protocol-decryptovk]_ There is a "grace period" of 32256 blocks starting from the block at which this -ZIP activates, during which note plaintexts with lead byte 0x01 MUST still be -accepted. +ZIP activates, during which note plaintexts with lead byte :math:`\mathtt{0x01}` +MUST still be accepted. Let ActivationHeight be the activation height of this ZIP, and let GracePeriodEndHeight be ActivationHeight + 32256. @@ -171,38 +196,44 @@ viewing key) is able to decrypt a note plaintext, it performs the following check on the plaintext lead byte, based on the height of the containing transaction: -* If the height is less than ActivationHeight, then only 0x01 is accepted as - the plaintext lead byte. +* If the height is less than ActivationHeight, then only :math:`\mathtt{0x01}` + is accepted as the plaintext lead byte. * If the height is at least ActivationHeight and less than GracePeriodEndHeight, - then either 0x01 or 0x02 is accepted as the plaintext lead byte. -* If the height is at least GracePeriodEndHeight, then only 0x02 is accepted - as the plaintext lead byte. + then either :math:`\mathtt{0x01}` or :math:`\mathtt{0x02}` is accepted as the + plaintext lead byte. +* If the height is at least GracePeriodEndHeight, then only :math:`\mathtt{0x02}` + is accepted as the plaintext lead byte. If the plaintext lead byte is not accepted then the note MUST be discarded. However, if an implementation decrypted the note from a mempool transaction and it was accepted at that time, but it is later mined in a block after the end of the grace period, then it MAY be retained. -A note plaintext with lead byte 0x02 contains a field :math:`\mathsf{rseed}` -that is a :math:`32`-byte sequence rather than a scalar value :math:`\mathsf{rcm}`. -The recipient, during decryption and in any later contexts, will interpret the -value :math:`\mathsf{rcm}` as the output of -:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))`. -Further, the recipient MUST compute :math:`\mathsf{esk}` as -:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))` and check -that :math:`\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}` and fail decryption -if this check is not satisfied. +A note plaintext with lead byte :math:`\mathtt{0x02}` contains a field +:math:`\mathsf{rseed}` that is a :math:`32`-byte sequence rather than a scalar +value :math:`\mathsf{rcm}`. The recipient, during decryption and in any later +contexts, will interpret the value :math:`\mathsf{rcm}` as the output of +:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))` in the case of +Sapling. Further, the recipient MUST compute :math:`\mathsf{esk}` as +:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))` in the case of +Sapling, and check that :math:`\mathsf{epk} = [\mathsf{esk}]\, \mathsf{g_d}`, +failing decryption if this check is not satisfied. For Orchard, an encoding of ρ +is appended to the PRF inputs, as for encryption. Consensus rule change for coinbase transactions ----------------------------------------------- After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in [#zip-0213]_, MUST have -note plaintext lead byte equal to 0x02. +note plaintext lead byte equal to :math:`\mathtt{0x02}`. This applies even during the “grace period”, and also applies to funding stream outputs [#zip-0207]_ sent to shielded payment addresses, if there are any. +Since NU5 activates after the end of the grace period [#zip-0252]_, Orchard +outputs will always require a note plaintext lead byte equal to +:math:`\mathtt{0x02}`. + Rationale ========= @@ -234,11 +265,17 @@ grace period (of about 4 weeks), it will be possible to identify wallets that are still sending plaintexts according to the old specification, and cajole their developers to make the required updates. For the avoidance of doubt, such wallets are non-conformant because it is a "MUST" requirement to -*immediately* switch to sending note plaintexts with lead byte 0x02 (and the -other changes in this specification) at the upgrade. Note that nodes will -clear their mempools when the upgrade activates, which will clear all -plaintexts with lead byte 0x01 that were sent conformantly and not mined -before the upgrade. +*immediately* switch to sending note plaintexts with lead byte +:math:`\mathtt{0x02}` (and the other changes in this specification) at the +upgrade. Note that nodes will clear their mempools when the upgrade activates, +which will clear all plaintexts with lead byte :math:`\mathtt{0x01}` that were +sent conformantly and not mined before the upgrade. + +Historical note: in practice some note plaintexts with lead byte +:math:`\mathtt{0x01}` were non-conformantly sent even after the end of the +specified grace period. ZecWallet extended its implementation of the grace +period by a further 161280 blocks (approximately 20 weeks) in order to allow +for recovery of these funds [#zecwallet-grace-extension]_. Security and Privacy Considerations @@ -247,10 +284,10 @@ Security and Privacy Considerations The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot -defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform -a linkability attack trivially in that case. +defeat the EC-DDH assumption of the Jubjub (or Pallas) elliptic curve, for it +could perform a linkability attack trivially in that case. -In the naive case where the protocol is modified so that :math:`\mathsf{esk}` +In the naïve case where the protocol is modified so that :math:`\mathsf{esk}` is supplied directly to the recipient (rather than derived through :math:`\mathsf{rseed}`) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using @@ -288,13 +325,22 @@ 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-saplingencrypt] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.1: Encryption (Sapling) `_ -.. [#protocol-abstractprfs] `Zcash Protocol Specification, Version 2020.1.15. Section 4.1.2: Pseudo Random Functions `_ -.. [#protocol-notept] `Zcash Protocol Specification, Version 2020.1.15. Section 5.5: Encodings of Note Plaintexts and Memo Fields `_ -.. [#protocol-saplingdecryptivk] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling) `_ -.. [#protocol-saplingdecryptovk] `Zcash Protocol Specification, Version 2020.1.15. Section 4.17.3: Decryption using a Full Viewing Key (Sapling) `_ -.. [#protocol-saplingsend] `Zcash Protocol Specification, Version 2020.1.15. Section 4.6.2: Sending Notes (Sapling) `_ +.. [#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 `_ .. [#zip-0207] `ZIP 207: Split Founders' Reward `_ .. [#zip-0213] `ZIP 213: Shielded Coinbase `_ .. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade `_ +.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade `_ +.. [#zecwallet-grace-extension] `Commit c31a04a in aditypk00/librustzcash: Move ZIP-212 grace period to end of April `_ diff --git a/zip-0213.html b/zip-0213.html index 7a3c8dcf3..e4414209e 100644 --- a/zip-0213.html +++ b/zip-0213.html @@ -20,12 +20,12 @@

The terms "Founders' Reward" and "funding stream" in this document are to be interpreted as described in ZIP 207 4.

Abstract

-

This proposal defines modifications to the Zcash consensus rules that enable coinbase funds to be mined to Sapling addresses. It does not disable the use of transparent addresses in coinbase transactions.

+

This proposal defines modifications to the Zcash consensus rules that enable coinbase funds to be mined to Sapling (and later Orchard) addresses. It does not disable the use of transparent addresses in coinbase transactions.

Motivation

Zcash inherited the concept of "coinbase transactions" from Bitcoin: special transactions inside each block that are allowed to have no inputs. These transactions are created by miners during block creation, and collect the block reward and transaction fees into new transparent outputs that can then be spent. They are also leveraged in Zcash for the Founders' Reward (and potentially for funding streams 4).

On the path to deprecating and removing Bitcoin-inherited transparent addresses within the Zcash network, a required step is to be able to create coinbase transactions that have no transparent outputs. However, Zcash was launched with a consensus rule preventing coinbase transactions from containing shielded outputs, instead enforcing that coinbase funds could not be spent in transactions with transparent outputs. This was partly in order to reduce the complexity of the original Zcash modifications to the Bitcoin Core codebase, but also because at the time, shielded transactions required significant memory and CPU resources to create.

-

The Sapling network upgrade 3 deployed architectural changes and performance improvements that make shielding funds directly in the coinbase transaction feasible. In order to reduce the complexity of the Sapling network upgrade, the existing consensus rules preventing coinbase transactions from containing shielded outputs were extended to cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in order to enable miners to start using Sapling addresses.

+

The Sapling network upgrade 3 deployed architectural changes and performance improvements that make shielding funds directly in the coinbase transaction feasible. In order to reduce the complexity of the Sapling network upgrade, the existing consensus rules preventing coinbase transactions from containing shielded outputs were extended to cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in order to enable miners to start using Sapling addresses. It will also be possible for miners to use Orchard addresses starting from activation of the NU5 upgrade 6.

Specification

Prior to activation of the Heartwood network upgrade, this existing consensus rule on coinbase transactions is enforced:

@@ -47,8 +47,13 @@ -
  • Full Sapling note decryption MUST succeed using the all-zero outgoing viewing key. More precisely, all Sapling outputs in coinbase transactions MUST have valid note commitments when recovered using a sequence of 32 zero bytes as the outgoing viewing key.
    • +
  • Full note decryption of shielded coinbase outputs MUST succeed using the all-zero outgoing viewing key. More precisely, all shielded coinbase outputs MUST have valid note commitments when recovered using a sequence of 32 zero bytes as the outgoing viewing key.
    • +

    Once the NU5 network upgrade activates:

    +
      +
    • Coinbase transactions MAY contain Sapling and/or Orchard outputs.
      • +
    +

    This does not require any change to the consensus rule given above; it is a consequence of other rules as of NU5 activation.

    Interaction with the Founders' Reward

    This ZIP does not alter the existing Founders' Reward addresses.

    @@ -66,7 +71,7 @@

    Revealing the coinbase output notes does not enable anyone else to detect when the note is spent, which removes the need for a separate shielding step like is enforced for transparent coinbase outputs.

    Deployment

    -

    This proposal will be deployed with the Heartwood network upgrade. 5

    +

    This proposal will be deployed with the Heartwood network upgrade. 5

    Reference Implementation

    https://github.com/zcash/zcash/pull/4256

    @@ -112,6 +117,14 @@ + + + + + + + +
    6ZIP 252: Deployment of the NU5 Network Upgrade
    diff --git a/zip-0213.rst b/zip-0213.rst index a090e269b..218f4d07a 100644 --- a/zip-0213.rst +++ b/zip-0213.rst @@ -28,8 +28,8 @@ Abstract ======== This proposal defines modifications to the Zcash consensus rules that enable coinbase -funds to be mined to Sapling addresses. It does not disable the use of transparent -addresses in coinbase transactions. +funds to be mined to Sapling (and later Orchard) addresses. It does not disable the use +of transparent addresses in coinbase transactions. Motivation @@ -55,7 +55,8 @@ improvements that make shielding funds directly in the coinbase transaction feas order to reduce the complexity of the Sapling network upgrade, the existing consensus rules preventing coinbase transactions from containing shielded outputs were extended to cover Sapling outputs. Therefore, it is now necessary to modify the consensus rules in -order to enable miners to start using Sapling addresses. +order to enable miners to start using Sapling addresses. It will also be possible for +miners to use Orchard addresses starting from activation of the NU5 upgrade [#zip-0252]_. Specification @@ -96,9 +97,17 @@ Once the Heartwood network upgrade activates: transactions include Founders’ Reward outputs [and potentially funding stream outputs]. -- Full Sapling note decryption MUST succeed using the all-zero outgoing viewing key. More - precisely, all Sapling outputs in coinbase transactions MUST have valid note commitments - when recovered using a sequence of 32 zero bytes as the outgoing viewing key. +- Full note decryption of shielded coinbase outputs MUST succeed using the all-zero + outgoing viewing key. More precisely, all shielded coinbase outputs MUST have valid + note commitments when recovered using a sequence of 32 zero bytes as the outgoing + viewing key. + +Once the NU5 network upgrade activates: + +- Coinbase transactions MAY contain Sapling and/or Orchard outputs. + +This does not require any change to the consensus rule given above; it is a consequence +of other rules as of NU5 activation. Interaction with the Founders' Reward @@ -194,3 +203,4 @@ References .. [#zip-0205] `ZIP 205: Deployment of the Sapling Network Upgrade `_ .. [#zip-0207] `ZIP 207: Split Founders' Reward `_ .. [#zip-0250] `ZIP 250: Deployment of the Heartwood Network Upgrade `_ +.. [#zip-0252] `ZIP 252: Deployment of the NU5 Network Upgrade `_