Support shielded coinbase in `getblocktemplate` for Sapling addresses

teor2345 commented 2 years ago

Motivation

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

Specifications

[Sapling onward] If effectiveVersion ≥ 4 and nSpendsSapling + nOutputsSapling > 0, then: – let bvkSapling and SigHash be as defined in § 4.13 ‘Balance and Binding Signature (Sapling)’ on p. 50; – bindingSigSapling MUST represent a valid signature under the transaction binding validating key bvkSapling of SigHash — i.e. BindingSigSapling.ValidatebvkSapling (SigHash, bindingSigSapling) = 1. [NU5 onward] As specified in § 5.4.7 ‘RedDSA, RedJubjub, and RedPallas’ on p. 90, the validation of the 𝑅 component of the signature changes to prohibit 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.

A coinbase transaction MUST NOT have any Spend descriptions.

[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 encoded sapling and unified containing sapling addresses in the miner address config
Create shielded outputs for miners using the Sapling address, according to the consensus rules
In the z_validateaddress and z_listunifiedreceivers RPCs, validate Sapling addresses and return those fields

Related issues

See #5929

teor2345 commented 2 years ago

We've been told by mining pools that no-one uses shielded coinbase, because it's expensive to generate the coinbase transactions.

We can re-open the ticket if a pool asks for it.

teor2345 commented 2 years ago

We've been told some mining pools are using this

mpguerra commented 2 years ago

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

teor2345 commented 1 year ago

Looking at the consensus rules, this is possibly a large ticket. Do we want to split it into Sapling and Orchard?

teor2345 commented 1 year ago

@mpguerra I suggest we split this ticket into Sapling and Orchard/Unified Addresses before we start on it.

teor2345 commented 1 year ago

Currently blocked by:

PR #5837
Splitting this ticket into Sapling and Orchard/Unified Addresses

mpguerra commented 1 year ago

Currently blocked by:

* PR [change(rpc): Refactor get block template RPC into stages #5837](https://github.com/ZcashFoundation/zebra/pull/5837)

* Splitting this ticket into Sapling and Orchard/Unified Addresses

See #5929

teor2345 commented 1 year ago

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

ZcashFoundation / zebra