* [bitcoindev] Bip54: add sequence, timestamp (and version) to GBT
@ 2026-02-09 19:37 Sjors Provoost
2026-02-10 5:12 ` Melvin Carvalho
0 siblings, 1 reply; 3+ messages in thread
From: Sjors Provoost @ 2026-02-09 19:37 UTC (permalink / raw)
To: Bitcoin Development Mailing List
Dear list,
BIP54 proposes constraining the coinbase transaction nLockTime and nSequence fields. Although it's not that difficult for pools to adjust their software to set the correct values based on the known block height, it seems appropriate and convenient to have node software provide these values via the getblocktemplate RPC.
SegWit had its own BIP for adding fields, but that was a significantly bigger lift. My preference would be to just extend BIP54, as I've done below.
Feel free to respond on the list or here: https://github.com/bitcoin/bips/pull/2097
Current version of BIP54: https://github.com/bitcoin/bips/blob/master/bip-0054.md
Here's the proposed expansion:
-------
## Miner forward compatibility
[...]
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. 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].
-------
Footnotes:
[^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`.
---
- Sjors Provoost
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1A3B8BFA-41A6-4D0F-BBE6-E791F9785A5E%40sprovoost.nl.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Bip54: add sequence, timestamp (and version) to GBT
2026-02-09 19:37 [bitcoindev] Bip54: add sequence, timestamp (and version) to GBT Sjors Provoost
@ 2026-02-10 5:12 ` Melvin Carvalho
2026-02-10 7:53 ` Sjors Provoost
0 siblings, 1 reply; 3+ messages in thread
From: Melvin Carvalho @ 2026-02-10 5:12 UTC (permalink / raw)
To: Sjors Provoost; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 4672 bytes --]
po 9. 2. 2026 v 20:46 odesílatel Sjors Provoost <sjors@sprovoost.nl> napsal:
> Dear list,
>
> BIP54 proposes constraining the coinbase transaction nLockTime and
> nSequence fields. Although it's not that difficult for pools to adjust
> their software to set the correct values based on the known block height,
> it seems appropriate and convenient to have node software provide these
> values via the getblocktemplate RPC.
>
> SegWit had its own BIP for adding fields, but that was a significantly
> bigger lift. My preference would be to just extend BIP54, as I've done
> below.
>
> Feel free to respond on the list or here:
> https://github.com/bitcoin/bips/pull/2097
BIP54’s consensus fixes are currently uncontroversial.
Bundling new getblocktemplate additions into it changes that and expands
the policy surface. Those additions should be specified separately, where
they belong.
>
>
> Current version of BIP54:
> https://github.com/bitcoin/bips/blob/master/bip-0054.md
>
> Here's the proposed expansion:
>
> -------
> ## Miner forward compatibility
>
> [...]
>
> 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. 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].
>
> -------
>
> Footnotes:
>
> [^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`.
>
> ---
>
> - Sjors Provoost
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/1A3B8BFA-41A6-4D0F-BBE6-E791F9785A5E%40sprovoost.nl
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYh%2BcjFBx42vhag3dd1zF0QFbgXHPL0fBUDFcA4aZY63EvQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6034 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Bip54: add sequence, timestamp (and version) to GBT
2026-02-10 5:12 ` Melvin Carvalho
@ 2026-02-10 7:53 ` Sjors Provoost
0 siblings, 0 replies; 3+ messages in thread
From: Sjors Provoost @ 2026-02-10 7:53 UTC (permalink / raw)
To: Melvin Carvalho; +Cc: 'Bitcoin Development Mailing List'
[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]
On Tue, Feb 10, 2026, at 06:12, Melvin Carvalho wrote:
>
>>
>> SegWit had its own BIP for adding fields, but that was a significantly bigger lift. My preference would be to just extend BIP54, as I've done below.
>>
>> Feel free to respond on the list or here: https://github.com/bitcoin/bips/pull/2097
>
> BIP54’s consensus fixes are currently uncontroversial.
>
> Bundling new getblocktemplate additions into it changes that and expands the policy surface. Those additions should be specified separately, where they belong.
Hi Melvin,
What do you mean by "policy surface" and how is it expanded? The fields do not add new rules to the proposal, they merely make implementation easier and safer.
Why do new fields "belong" elsewhere?
- Sjors
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/081ed43e-04e7-40d5-b61a-dc3957dc5d08%40app.fastmail.com.
[-- Attachment #2: Type: text/html, Size: 2152 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-02-10 9:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-09 19:37 [bitcoindev] Bip54: add sequence, timestamp (and version) to GBT Sjors Provoost
2026-02-10 5:12 ` Melvin Carvalho
2026-02-10 7:53 ` Sjors Provoost
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox