Sv2NewTemplate: add coinbase_witness

[Sjors]

Adding coinbase_witness to the Sv2NewTemplate message so that it is automatically propagated to other roles in the Stratum v2 ecosystem, rather than assumed to be 0x00...00.

This ensures that if this value ever gets consensus meaning, miners only need to upgrade their node software, not the rest of the mining stack.

Marked draft because it requires a Stratum v2 spec change as well as support on the SRI side.

There's no rush to do this, since there are currently no soft fork proposals that change the witness reserve value. However, the switch to IPC may be a good opportunity to make a breaking change.

See also:

• https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure
• add BIP141 conventions for serialized coinbase sv2-spec#153 (comment)

[plebhash]

if I were to write something similar to #15, I'd call this field NewTemplate.coinbase_witness instead of NewTemplate.coinbase_witness_reserved_value

that's because BIP141 says:

The new commitment in coinbase transaction is a hash of the witness root hash and a witness reserved value. The witness reserved value currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in coinbase becomes:

 Double-SHA256(Witness root hash|Hash(new commitment|witness reserved value))

For backward compatibility, the Hash(new commitment|witness reserved value) will go to the coinbase witness, and the witness reserved value will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.

Essentially, whoever receives NewTemplate needs to know the contents of the Coinbase witness, which now can be whatever (and it's tipically 0x000...000), and in the future would carry Hash(new commitment|witness reserved value)

In other words, witness reserved value happens to be the in the Coinbase witness today, but it could be somewhere else tomorrow. And what we really want to know is the Coinbase witness so that we can create a Coinbase that will be coherent with the witness commitment.

[Sjors]

My initial idea was also to call it coinbase_witness, however a witness is a stack of elements and you would expect it to be encoded that way. But the coinbase witness can never have more than one element and that one element MUST be 32 bytes.

That said, I agree that coinbase_witness_reserved_value is also wrong.

Perhaps coinbase_witness_commitment is better. But the word "commitment" is heavily overloaded.

So maybe coinbase_witness is fine, it should be clear enough to how to use it.

[Sjors]

Rebased after:

• test: mock IPC connection to node #8

Conflict resolution can be reviewed with:

PREV=979ad78b326d16a6e66c2bb1e3e3908538275a97  N=1 && git range-diff `git merge-base --all HEAD $PREV`...$PREV HEAD~$N...HEAD