Rationale for nAGExpiryHeight

We introduce the nAGExpiryHeight field in this transaction format in order to be forward compatible with Swaps over ZSAs, as proposed in ZIP 228 19. For the OrchardZSA protocol, which does not make use of an additional expiry height for transactions, we set the value of nAGExpiryHeight to be 0 by consensus. This serves as a default value to represent the situation where there is no expiry, analogous to the convention adopted for nExpiryHeight in ZIP 203 [#zip-0203].

Rationale for including Burn fields inside OrchardZSA Action Groups

Note that the v6 transaction format includes the burn fields of the transaction inside the OrchardZSA Action Group rather than at the transaction level. This is a design choice that considers the future scenario where Action Groups may be generated by different parties before being bundled together into a transaction. In such a scenario, the individual parties can burn Assets of their choice in their corresponding Action Groups. Maintaining the burn fields at the transaction level would provide the ability to burn Assets only to the party performing the bundling of the Action Groups.

Sapling Note Plaintext

In order to accommodate the change needed for memo bundles 22, a v6-onward Sapling note plaintext must include a 32-byte memo key \(\mathsf{K^{memo}} : \mathbb{B}^{\mathbb{Y}[32]\!\) , rather than a 512-byte plaintext memo.

The corresponding changes to the Zcash Protocol Specification are specified in 23.

The encoding of a v6-onward Sapling note plaintext in § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ 7 is similarly updated and is now defined as:

Orchard Note Plaintext

As well as the same change to accommodate memo bundles as above, OrchardZSA notes have an additional \(\mathsf{AssetBase}\) field, which needs to be included (as its byte sequence encoding \(\mathsf{asset\_base}\!\) ) in a v6-onward Orchard note plaintext.

Let \(\mathcal{V}^{\mathsf{Orchard}}\) be as defined in § 5.4.8.3 ‘Homomorphic Pedersen commitments (Sapling and Orchard)’ 6.

An Orchard note is essentially equivalent to an OrchardZSA note with \(\mathsf{AssetBase} = \mathcal{V}^{\mathsf{Orchard}}\!\) ; in particular, they have the same note commitment (as defined in 15), and need not be distinguished in note plaintexts.

Each v6-onward Orchard note plaintext consists of

where (consistent with 15) \(\mathsf{asset\_base}\) is \(\mathsf{LEBS2OSP}_{\ell_{\mathbb{P}}}(\mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase}))\!\) .

The encoding of a v6-onward Orchard note plaintext in § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ 7 is similarly updated and is now defined as:

The encodings of \(\mathsf{d}\!\) , \(\mathsf{v}\!\) , and \(\mathsf{rseed}\) remain unchanged from the previous specification in §5.5 ‘Encodings of Note Plaintexts and Memo Fields’ of the Zcash Protocol Specification 7.

Non-normative note: The use of the \(\mathsf{rseed}\) in Orchard note decryption changes, but its type and encoding do not.

Rationale for requiring the lead byte to be 0x03 in v6

It was decided to synchronize the changes to note encryption required for quantum recoverability, ZSA support, and memo bundles with a change to the transaction format, for two reasons:

• This was necessary because the note ciphertexts must be a different size to those in v5 transactions — to accommodate the ZSA \(\mathsf{AssetBase}\) field for Orchard, and due to changing the 512-byte \(\mathsf{memo}\) field to a 32-byte \(\mathsf{K^{memo}}\) field for both Sapling and Orchard. In fact the latter change makes it impossible to retain the lead-byte \(\mathtt{0x02}\) format unchanged, because the note ciphertext is not large enough (in either Sapling or Orchard outputs) for a 512-byte memo.
• The quantum recoverability change did not necessarily have to be done at the same time as the ZSA and memo bundle changes. However, it would have significantly increased overall protocol complexity for there to be a separate note plaintext format for quantum-recoverable notes. Also, doing it at the same time minimizes the risk that non-conformant wallets would create outputs after this change that could not be successfully decrypted by conformant wallets. That could potentially result in inaccessible funds, as was observed with the previous note plaintext change at the Canopy upgrade 10. (As noted above, it is still possible for funds to be temporarily stuck if a receiving wallet does not fully support v6 transactions, but this is less problematic because upgrading the wallet will unstick them.)

Although the ZSA and quantum recoverability-related note plaintext changes do not apply to Sapling, the change from \(\mathsf{memo}\) to \(\mathsf{K^{memo}}\) justifies changing the lead byte for both Sapling and Orchard.

Sending v6 transactions

All Zcash wallets SHOULD, without undue delay, switch to sending only v6 transactions once they are allowed on the network. This applies to all transactions regardless of whether they transact in native or non-native assets, or whether they use other v6 features.

Rationale for sending v6 transactions

Support for receiving funds in v6 transactions

Zcash wallets MUST support parsing and processing v6 transactions by the time they are allowed on the network (scheduled for NU7 activation). This includes detecting and decrypting lead-byte \(\mathtt{0x03}\) note plaintexts and memo bundles.

The necessary changes to note decryption are specified in ZIP 231 20, ZIP 226 14, and draft-ecc-quantum-recoverability 30 (which defines the necessary changes to the Zcash protocol specification). Note that the changes arising from 20 apply also to Sapling outputs.

In the event that a wallet implementation, contrary to the above requirement, does not support decrypting outputs of v6 transactions (or some subset of them) immediately once they are allowed on the network, it MUST rescan those outputs once that support is added.

Rationale for being ready to receive v6 transactions at their activation

Note plaintexts with lead byte \(\mathtt{0x03}\!\) , which are required for Orchard notes in v6 transactions, can be sent to any Orchard address.

These notes use a different computation of \(\mathsf{rcm}\) and \(\text{ψ}\) from \(\mathsf{rseed}\!\) , which is necessary in order to achieve quantum recoverability as explained in 31. They also have a new \(\mathsf{AssetBase}\) field used to support ZSAs. Therefore, they cannot be validated or spent without making all of the specified changes. A wallet attempting to non-conformantly use the note decryption algorithm for lead byte \(\mathtt{0x02}\) would compute a different note commitment \(\mathsf{cm}_x\) and would reject the note.

If wallets do not support v6 transactions and lead-byte \(\mathtt{0x03}\) note decryption immediately, then funds may be sent to them that they cannot receive. This affects both the existing Orchard functionality, and receiving non-native ZSA assets.

This situation is different from previous upgrades that introduced a new shielded pool, such as the Sapling and NU5 upgrades, because in those cases the new pool used an entirely new address type, and existing wallets would not have given out addresses of those types.

Furthermore, as described in [Sending v6 transactions]_, other wallets can be expected to immediately start sending v6 transactions as soon as they are allowed, and so all wallets need to be ready to receive them at that point.