Add BIP-xxxx: additional coinbase fields for GBT

Author: Sjors

bip-coinbase-fields-bip54.md

@@ -0,0 +1,103 @@
+```
+  BIP: ?
+  Layer: API/RPC
+  Title: getblocktemplate - additional coinbase fields
+  Authors: Sjors Provoost <sjors@sprovoost.nl>
+  Status: Draft
+  Type: Specification
+  Assigned: ?
+  License: BSD-2-Clause
+  Requires: 22
+```
+
+## Abstract
+
+This BIP describes modifications to the `getblocktemplate` JSON-RPC call
+([BIP 22](bip-0022.mediawiki)) to allow servers to specify the coinbase
+transaction's `nVersion`, `nLockTime`, and `nSequence` fields.
+
+## Motivation
+
+[BIP 54](bip-0054.md) proposes new consensus rules that would constrain the
+coinbase transaction's `nLockTime` and `nSequence` fields. Although BIP 54
+is the direct motivation for this BIP, it can be implemented independently.
+This BIP only adds these fields to the server response, it does not constrain
+their values.
+
+BIP 54 does not constrain `nVersion`, but it's included in this BIP so that
+`getblocktemplate` now covers all coinbase transaction fields.[^complete]
+
+## Specification
+
+### Block Template
+
+The template Object is extended to include new keys:
+
+| Key | Required | Type | Description |
+|-----|----------|------|-------------|
+| `coinbase_version` | Yes | Number | coinbase `nVersion` value |
+| `coinbase_locktime` | Yes | Number | coinbase `nLockTime` value |
+| `coinbase_sequence` | Yes | Number | coinbase `nSequence` value |
+
+Types are JSON types as defined in [BIP 22](bip-0022.mediawiki).
+
+The `coinbase_version` field specifies the value that MUST be
+used for the coinbase transaction's `nVersion` field.[^version]
+
+The `coinbase_locktime` field specifies the exact value that
+SHOULD be used for the coinbase transaction's `nLockTime` field.
+If BIP54 is activated then it MUST be used.[^locktime]
+
+The `coinbase_sequence` field specifies a value that MUST be used
+for the coinbase transaction input's `nSequence` field.[^sequence]
+
+## Rationale
+
+Included as footnotes.
+
+## Backward Compatibility
+
+Servers that do not support this BIP will not include the new fields. Clients
+that do not understand these fields may ignore them. However, they will produce
+invalid blocks if [BIP 54](bip-0054.md) is activated, unless they independently
+implement the required constraints.
+
+## Reference Implementation
+
+- Bitcoin Core: [bitcoin/bitcoin#34419](https://github.com/bitcoin/bitcoin/pull/34419)
+
+## Copyright
+
+This BIP is licensed under the BSD 2-clause license.
+
+[^version]: **What value should servers use for `coinbase_version`?**
+    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 68](bip-0068.mediawiki), but its relative
+    lock-time rules do not apply to the coinbase input. If future consensus
+    rules constrain transaction versions, servers MUST reflect those rules in
+    `coinbase_version`. Clients MUST use this value so that they don't need
+    to be updated again later.
+
+[^locktime]: **Why SHOULD vs MUST?**
+    Unless BIP 54 is not activated, the `nLockTime` field could potentially be
+    used as an `extraNonce`, which downstream software may need to roll. This
+    use case would be ruled out by BIP 54 activation. It requires an `nLockTime`
+    that's interpreted as a height and also constrains `nSequence`. That leaves
+    no flexibility in `nLockTime`.
+
+[^sequence]: **Why not use a bit mask?**
+    The only restriction BIP 54 proposes for `nSequence` is to disallow
+    `0xffffffff`. The server could communicate this intention via a bit mask,
+    but for simplicity it just provides the entire `nSequence` value. Clients
+    MUST use this value, so that future soft forks can safely add additional
+    constraints.
+
+[^complete]: **Does `getblocktemplate` now cover all coinbase transaction
+    fields?**
+    All fields that could potentially be constrained by a soft fork are now
+    covered. 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.
+
+