Bip54: add sequence, timestamp (and version) to GBT

This initiative, while straightforward, requires mining pools to update their software to maintain forward compatibility. The proposal identifies a gap in the availability of open-source reference software for creating coinbase transactions, urging mining pools to modify their processes in anticipation of future changes. To facilitate these modifications, BIP54 recommends adding new fields to the getblocktemplate JSON-RPC call, contingent on support from node software developers. The enhancements proposed include the introduction of three specific keys: coinbase_locktime, coinbase_sequence, and coinbase_version in the getblocktemplate function as defined in BIP22. These additions aim to pre-emptively align coinbase transactions with potential future soft forks by specifying exact values for nLockTime, suggesting preferred nSequence values (excluding 0xffffffff), and recommending an nVersion value for the coinbase transaction.

The rationale behind these requirements is thoroughly discussed, highlighting the necessity of compliance to future-proof transactions against possible protocol amendments. It points out the simplicity of implementing these changes due to the fixed nature of certain coinbase input fields by consensus, like the prevout txid and vout index. Despite the absence of current limitations on the nVersion of coinbase transactions, including it in the getblocktemplate ensures that mining software remains up-to-date without the need for additional modifications in response to future soft forks. For further details and discussions, the document encourages contributors and interested parties to visit the provided GitHub links.

A subsequent email exchange reveals concerns regarding the integration of new getblocktemplate additions into BIP54, suggesting that doing so could controversially expand the "policy surface." However, it's clarified that these fields do not introduce new rules but rather simplify and secure implementation. Questions about why these fields should be specified elsewhere are raised, emphasizing the practicality and safety the proposed changes aim to achieve.