Populate transparent coinbase transaction data for BlockTemplate

[oxarbitrage]

Motivation

The coinbasetxn field of the BlockTemplate is a struct:(#5235 (comment)) and can be complex enough to implement it in a separated ticket.

Specifications

• [NU5 onward] The transaction version number MUST be 4 or 5. If the transaction version number is 4 then the version group ID MUST be 0x892F2085. If the transaction version number is 5 then the version group ID MUST be 0x26A7270A.
• [NU5 onward] If effectiveVersion ≥ 5, the nConsensusBranchId field MUST match the consensus branch ID used for SIGHASH transaction hashes, as specified in [ZIP-244].
• 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.
• A coinbase transaction for a block at block height greater than 0 MUST have a script that, as its first item, encodes the block height height as follows. For height in the range {1 .. 16}, the encoding is a single byte of value 0x50 + height. Otherwise, let heightBytes be the signed little-endian representation of height, using the minimum nonzero number of bytes such that the most significant byte is < 0x80. The length of heightBytes MUST be in the range {1 .. 5}. Then the encoding is the length of heightBytes encoded as one byte, followed by heightBytes itself. This matches the encoding used by Bitcoin in the implementation of [BIP-34] (but the description here is to be considered normative).
• A coinbase transaction script MUST have length in {2 .. 100} bytes.
• [NU5 onward] The nExpiryHeight field of a coinbase transaction MUST be equal to its block height .

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

Tasks

Shielded coinbase is out of scope, most miners don't use it.

• Create CoinBaseTxn struct.

• Populate on getblocktemplate response

  • The coinbase transaction has the following fixed values:
    • required: true
  • Here are the fields that are calculated from the transactions, including the coinbase transaction:
    • defaultroots
      • authdataroot
      • merkleroot

• Test: TODO

Depends on #5451

[teor2345]

@oxarbitrage I think the coinbase transaction depends on the transactions from ticket #5454, and the miner address from ticket #5456, because it includes the transaction fee, and pays the miner reward and fee to the miner.

[teor2345]

Here are the fields that are calculated from the transactions, including the coinbase transaction:

• defaultroots
  • authdataroot
  • merkleroot

And here are the fields that are calculated from the transactions, and the state request in #5455:

• defaultroots
  • blockcommitmentshash (same value for lightclientroothash, finalsaplingroothash, and blockcommitmentshash)

Can I edit the ticket?

[teor2345]

I think we might want to open another ticket for shielded coinbase, most of the existing coinbase transactions are transparent. (All the funding streams are transparent, and almost all miner payments are transparent.)

[mpguerra]

I think we might want to open another ticket for shielded coinbase, most of the existing coinbase transactions are transparent. (All the funding streams are transparent, and almost all miner payments are transparent.)

Let's open the issue, however I'm not sure that we need to do this as part of an MVP for the getblocktemplate work.

[mpguerra]

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

[teor2345]

I split #5579 out of this ticket, because the state request isn't ready yet.