bip54: additional coinbase fields for GBT

README.mediawiki

@@ -512,6 +512,13 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
 | Dmitry Petukhov
 | Informational
 | Complete
+|-
+| [[bip-0089.mediawiki|89]]
+| Applications
+| Chain Code Delegation
+| Jesse Posner, Jurvis Tan
+| Specification
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0090.mediawiki|90]]
 |
@@ -617,6 +624,13 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
 | Gavin Andresen
 | Specification
 | Closed
+|-
+| [[bip-0110.mediawiki|110]]
+| Consensus (soft fork)
+| Reduced Data Temporary Softfork
+| Dathon Ohm
+| Specification
+| Draft
 |- style="background-color: #cfffcf"
 | [[bip-0111.mediawiki|111]]
 | Peer Services
@@ -1171,6 +1185,13 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
 | Specification
 | Closed
 |-
+| [[bip-0346.md|346]]
+| Consensus (soft fork)
+| OP_TXHASH
+| Steven Roose, Brandon Black
+| Specification
+| Draft
+|-
 | [[bip-0347.mediawiki|347]]
 | Consensus (soft fork)
 | OP_CAT in Tapscript
@@ -1360,6 +1381,13 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
 | Informational
 | Draft
 |-
+| [[bip-0434.md|434]]
+| Peer Services
+| Peer Feature Negotiation
+| Anthony Towns
+| Specification
+| Draft
+|-
 | [[bip-0443.mediawiki|443]]
 | Consensus (soft fork)
 | OP_CHECKCONTRACTVERIFY

bip-0054.md

@@ -150,12 +150,38 @@ that include 64-byte transactions.
 The coinbase transaction is usually crafted by mining pool software. To the best of the authors'
 knowledge, there does not exist an open source reference broadly in use today for such software.
 We encourage mining pools to update their software to craft coinbase transactions that are
-forward-compatible with the changes proposed in this BIP.
+forward-compatible with the changes proposed in this BIP. This can be done by using the new
+`getblocktemplate` fields described below, once node software supports it.
+
+## getblocktemplate changes
+
+The template Object of the `getblocktemplate` JSON-RPC call ([bip-0022][BIP22]) is extended with
+the following keys:
+
+| Key | Required | Type | Description |
+|-----|----------|------|-------------|
+| `coinbase_locktime` | Yes | Number | coinbase `nLockTime` value |
+| `coinbase_sequence` | Yes | Number | coinbase `nSequence` value |
+| `coinbase_version` | Yes | Number | coinbase `nVersion` value |
+
+Types are JSON types as defined in [bip-0022][BIP22].
+
+The `coinbase_locktime` field specifies the exact value that MUST be used for the coinbase
+transaction's `nLockTime` field.
+
+The `coinbase_sequence` field specifies a value that SHOULD be used for the coinbase transaction
+input's `nSequence` field. If a different value is used, it MUST NOT be `0xffffffff`[^12].
+
+The `coinbase_version` field specifies the value that SHOULD be used for the coinbase transaction's
+`nVersion` field[^13].
+
 
 ## Reference implementation
 
 An implementation of BIP54 for Bitcoin Core is available [here][inquisition-implem].
 
+The `getblocktemplate` extension is implemented in [bitcoin/bitcoin#34419][GBT implem].
+
 ## Test vectors
 
 Documented test vectors are available [here](./bip-0054/test_vectors/) for all mitigations
@@ -218,6 +244,23 @@ bip-0034 height commitment and the corresponding future block height.
 coinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent
 for any implementation which enforces `nLockTime` from the genesis block, which is the behaviour
 notably of Bitcoin Core but also of all other implementations the authors are aware of.
+[^12]: **Why SHOULD for `coinbase_sequence`?**
+  The only consensus constraint on `nSequence` is to disallow `0xffffffff`.
+  The server could communicate this via a bit mask, but for simplicity it
+  provides the entire `nSequence` value. Clients SHOULD use this value, so
+  that future soft forks can safely add additional constraints.
+[^13]: **Why is `coinbase_version` included?**
+  This BIP does not constrain the coinbase transaction's `nVersion`, but
+  including it means `getblocktemplate` now covers all coinbase transaction
+  fields that could potentially be constrained by a future soft fork. The
+  coinbase input's prevout txid (32 zero bytes) and vout index (`0xffffffff`)
+  are fixed by consensus, so they can be safely hardcoded in mining software.
+  At the time of writing, there is no consensus constraint on transaction
+  versions. Transaction version 2 is the latest version with defined
+  semantics, as specified in [bip-0068][BIP68], but its relative lock-time
+  rules do not apply to the coinbase input. Nonetheless, clients SHOULD use
+  this value so that they don't need to be updated if a future soft fork
+  constrains `nVersion`.
 
 [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
 [BIP-XXXX]: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
@@ -242,3 +285,6 @@ notably of Bitcoin Core but also of all other implementations the authors are aw
 [Core 29.0]: https://bitcoincore.org/en/releases/29.0
 [inquisition-implem]: https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup
 [Core 30.0]: https://bitcoincore.org/en/releases/30.0
+[BIP22]: https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki
+[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
+[GBT implem]: https://github.com/bitcoin/bitcoin/pull/34419