Shielded sighash typing

[daira]

Idea from a pairing between @str4d, @nuttycom and I.

Motivation

The current approach to computing the sighash for shielded spend auth signatures is to effectively always use SIGHASH_ALL. This is less flexible than the transparent sighash, which uses a sighash variant chosen at signing time to control internal modifications to the sighash algorithm. The sighash variant is treated as a set of bitflags up to and including Canopy, and as a defined set of variants from NU5 onward; see the first point in the ZIP 244 rationale.

Proposal

Just use directly defined variants for "shielded sighash types".

• The variant chosen by a signer for a particular spend is stored in the authorizing data, next to the signature.
  • Kind of like transparent sighash byte but explicitly in transaction format instead of concatenated to the signature.
• Spend auth sigs commit to the sighash variant they are using at the top level of the sighash (e.g. next to consensus branch ID in the personalization field). This also provides domain separation between variants.

Rationale

• Orchard flags are effecting data. Having one of them define the authorizing data starts mixing concerns, and has consequential restricting effects on the order of multi-party transaction construction.
  • A concrete example for Asset Swaps:
    • Maker provides an Action Group with signatures
    • Taker provides an Action Group, and signs the whole transaction
    • Maker is now unable to change their signature to also sign the whole transaction, unless they happen to be online at the same time as the Taker. Otherwise it would invalidate Taker's signature, unless the Taker signed "twice" once for each flag combination (which has exponential blowup and you would have to anticipate it).
  • Decoupling from the effecting data means that in the above flow, the Maker could supply the full signature any time between Taker signing and the tx being submitted to the chain. So there is a weaker liveness requirement.
• With sighash variant versioning, it lets us swap out the sighash variants in consensus separately from transaction versions.
  • Use case: if we find a vuln in the original sighash specified alongside a tx version, we can define a new variant with the fix, and then in consensus rules require that no tx use the "v6 tx v0 sighash variant" to fully eliminate the vuln.
• Same rationale as why the transparent sighash types were restricted to a well-defined set in NU5: hardware wallets can better reason about the upper limits on hashing they may need to perform.
  • In our case, the set of allowed sighash variants per transaction version would be committed to by the consensus branch ID (just like with the set of allowed transaction versions), and thus is well defined for hardware wallets.
• We no longer need to pay the complexity cost of defining Asset Swap-compatible sighashing on the NU7 critical path. We only need to ensure that the v6 transaction format contains all the data necessary for Asset Swaps (and commit to it like ZIP 244 does, via effectively signing the txid), and defining the sighash leveraging it can be done on the NU8 timeline (by defining "v6 tx v1 sighash" to be allowed from NU8 activation).
• If only one variant is ever defined for a given transaction version, then this mechanism is effectively free from an analysis point of view.
• Defining "sighash variants" as numbered versions means that authorizing data commits to an algorithm rather than a behaviour. Algorithms are the things we want to be able to swap out, which requires versioning; trying to adapt transparent sighash types for this purpose would be torturous.
  • We may still want to use the Orchard flags for Asset Swaps as a means of specifying alternative behaviours (as part of the effecting data), that a v1 sighash algorithm is constructed to leverage. But this mechanism provides flexibility in whether we want variations in spend authorization to be controlled by effecting or authorizing data.
• There is no need to add this for Sapling, because the motivation is to provide new functionality for protocols that we intend to extend, i.e. Orchard[ZSA], and we have no intention to extend Sapling (partly due to the cost of the trusted setup).
• In the case of transparent, we already have the sighash flags. These only permit expressing behaviours not algorithms, and so transparent signers would still be limited solely to the v0 sighash variant defined at transaction format specification time. We consider this an acceptable limitation because we want to focus future protocol development on shielded.