Support shielded coinbase in getblocktemplate for Orchard Unified addresses

[mpguerra]

Motivation

Some miners use shielded coinbase, but it's pretty rare.

Specifications

• [NU5 onward] If effectiveVersion ≥ 5 and nActionsOrchard > 0, then:
  – let bvkOrchard and SigHash be as defined in § 4.14 ‘Balance and Binding Signature (Orchard)’ on p. 52;
  – bindingSigOrchard MUST represent a valid signature under the transaction binding validating key bvkOrchard of SigHash — i.e. BindingSigOrchard.ValidatebvkOrchard (SigHash, bindingSigOrchard) = 1. As specified in § 5.4.7 ‘RedDSA, RedJubjub, and RedPallas’ on p. 90, validation of the 𝑅 component of the signature prohibits non-canonical encodings.
• The total value in zatoshi of transparent outputs from a coinbase transaction, minus vbalanceSapling, minus vbalanceOrchard, MUST NOT be greater than the value in zatoshi of block subsidy plus the transaction fees paid by transactions in this block.
• [NU5 onward] In a version 5 coinbase transaction, the enableSpendsOrchard flag MUST be 0.
• [NU5 onward] In a version 5 transaction, the reserved bits 2 .. 7 of the flagsOrchard field MUST be zero.
• [Heartwood onward] All Sapling and Orchard outputs in coinbase transactions MUST decrypt to a note plaintext , i.e. the procedure in § 4.19.3 ‘Decryption using a Full Viewing Key (Sapling and Orchard)’ on p. 67 does not return ⊥, using a sequence of 32 zero bytes as the outgoing viewing key. (This implies that before Canopy activation, Sapling outputs of a coinbase transaction MUST have note plaintext lead byte equal to 0x01.)
• [Canopy onward] Any Sapling or Orchard output of a coinbase transaction decrypted to a note plaintext according to the preceding rule MUST have note plaintext lead byte equal to 0x02. (This applies even during the “grace period” specified in [ZIP-212].)

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

Designs

• Accept unified containing orchard addresses in the miner address config
• In the getblocktemplate RPC, create shielded outputs for miners using the Orchard address, according to the consensus rules
• In the z_validateaddress and z_listunifiedreceivers RPCs, validate Orchard addresses and return those fields

Related issues

See #5472

[teor2345]

I deleted the Sapling-specific consensus rules from this ticket, because they are covered by #5472.

[mpguerra]

Hey team! Please add your planning poker estimate with Zenhub @arya2 @conradoplg @dconnolly @oxarbitrage @teor2345 @upbqdn

[teor2345]

I updated the tags to match #5472, and also made this ticket depend on #5472, because they change some of the same consensus rules.

[mpguerra]

@daira @str4d is this something that is supported by zcashd? Should this be implemented in Zebra as part of zcashd deprecation