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

This initiative addresses the lack of widely used open-source reference software for crafting these transactions and suggests adjustments through new fields in the getblocktemplate JSON-RPC call, awaiting node software support. An expansion within BIP54 introduces key changes to the getblocktemplate function as outlined in BIP22, adding coinbase_locktime, coinbase_sequence, and coinbase_version keys to set specific values for these fields, thereby streamlining the compatibility of coinbase transactions with potential future soft forks. The rationale behind these updates emphasizes future-proofing transactions against protocol changes, highlighting how some coinbase input fields are fixed by consensus, simplifying their implementation in mining software. Additionally, including the nVersion in getblocktemplate ensures that mining software can remain up-to-date without further modifications for future soft forks. For more information and discussion, interested parties are directed to https://github.com/bitcoin/bips/pull/2097 and to review the current version of BIP54 at https://github.com/bitcoin/bips/blob/master/bip-0054.md.

The dialogue surrounding BIP54 includes concerns about its proposal to incorporate new additions into the getblocktemplate within the same BIP. Critics argue that this could unnecessarily complicate matters by expanding the policy surface and suggest that these additions be specified in a separate document or proposal for focused discussion. This viewpoint underscores the need to distinguish between consensus fixes, which are not contentious, and policy surface expansions, which could benefit from dedicated examination.

Further discussions on the Bitcoin Development Mailing List have explored the concept of "policy surface" in relation to Bitcoin development, questioning why adding new fields to a proposal is seen as an expansion of this surface rather than a beneficial adjustment. There's curiosity about the reasoning behind segregating these new fields into different parts of the proposal or discussion, suggesting a nuanced view of how modifications are categorized and their impact on Bitcoin's developmental governance.

An update in the discussion indicated the removal of the version field from the proposal and reference implementation due to concerns over expanding the scope too much, especially since BIP145 does not specify fields for the coinbase witness and for the SegWit commitment. This decision highlights ongoing efforts to refine proposals to ensure clarity and focus, acknowledging the complexities involved in updating protocols like Bitcoin.