Do we need to validate nSpendsSapling, nOutputsSapling, and nActionsOrchard limits in V5 transactions?

[teor2345]

Motivation

We need to validate Orchard transactions from NU5 onwards.

Orchard signatures and proofs are already covered by other tickets, but we should check all the fields are being validated.

Specifications

TODO: Are there any other orchard or NU5 consensus rules?

Shielded Input and Output Limits

[NU5 onward] nSpendsSapling, nOutputsSapling, and nActionsOrchard MUST all be less than 2^16.

Explanation:

[NU5 onward] The rule that nSpendsSapling, nOutputsSapling, and nActionsOrchard MUST all be less than 2^16, is technically redundant because a transaction that could violate this rule would not fit within the 2 MB block size limit. It is included in order to simplify the security argument for balance preservation.

Note:

• We could implement this rule directly, but we already limit these sizes using T::max_allocation for spends, outputs, and actions. So we could just add a comment about this rule.
• We could also skip this rule, but add a compile-time assertion that it is redundant, using the same minimum spend, output, and action sizes as T::max_allocation

https://zips.z.cash/protocol/protocol.pdf#txnencodingandconsensus

Solution

TODO: Work out how to check each consensus rule

[teor2345]

I removed this rule, because it is validated by the orchard proof circuit (#1912):

Orchard Flags

[NU5 onward] The flags in flagsOrchard allow a version 5 transaction to declare that no funds are spent from Orchard notes (by setting enableSpendsOrchard to 0), or that no new Orchard notes with nonzero values are created (by setting enableOutputsOrchard to 0).

Explanation:

This has two primary purposes. First, the enableSpendsOrchard flag is set to 0 in version 5 coinbase transactions to ensure that they cannot spend from existing Orchard outputs. This maintains a restriction present in coinbase transactions for transparent, Sprout, or Sapling funds, which would not otherwise be enforceable in the combined Action transfer design. Second, if a security vulnerability were found that affected only the input side, or only the output side of the Action circuit, it would be possible to use these flags in a soft fork (i.e. a strictly contracting consensus change) to effectively “switch off” non-zero-valued transfers only on the relevant side. Setting either of these flags to 0 does not affect the presence or validation of spend authorization signatures, or other consensus rules associated with Action descriptions. These note spending and creation consensus rules are specified as part of the Orchard Action statement (§ 4.17.4 ‘Action Statement (Orchard)’ on p. 58).

https://zips.z.cash/protocol/protocol.pdf#txnencodingandconsensus

[teor2345]

This rule is technically redundant, so I'm moving it to sprint 21.

[mpguerra]

Moving to Sprint 24 as a final sanity check before we decide to remove it from the NU5 mainnet activation/stable release goal

[daira]

I removed this rule, because it is validated by the orchard proof circuit (#1912):

Orchard Flags

[NU5 onward] The flags in flagsOrchard allow a version 5 transaction to declare that no funds are spent from Orchard notes (by setting enableSpendsOrchard to 0), or that no new Orchard notes with nonzero values are created (by setting enableOutputsOrchard to 0).

Explanation:

This has two primary purposes. First, the enableSpendsOrchard flag is set to 0 in version 5 coinbase transactions to ensure that they cannot spend from existing Orchard outputs. This maintains a restriction present in coinbase transactions for transparent, Sprout, or Sapling funds, which would not otherwise be enforceable in the combined Action transfer design. Second, if a security vulnerability were found that affected only the input side, or only the output side of the Action circuit, it would be possible to use these flags in a soft fork (i.e. a strictly contracting consensus change) to effectively “switch off” non-zero-valued transfers only on the relevant side. Setting either of these flags to 0 does not affect the presence or validation of spend authorization signatures, or other consensus rules associated with Action descriptions. These note spending and creation consensus rules are specified as part of the Orchard Action statement (§ 4.17.4 ‘Action Statement (Orchard)’ on p. 58).

https://zips.z.cash/protocol/protocol.pdf#txnencodingandconsensus

Is this comment on the right issue? The enable* flags are independent of the limits on the number of spends, outputs, and actions.

[teor2345]

Is this comment on the right issue? The enable* flags are independent of the limits on the number of spends, outputs, and actions.

Previously, this ticket had a list of extra Orchard rules we needed to validate.

Once I removed the redundant rule, I renamed the ticket based on the single remaining rule.