bip54: additional coinbase fields for GBT by Sjors · Pull Request #1 · Sjors/bips

Sjors · 2026-01-27T17:01:07Z

PR to self for initial feedback.

(initially this was intended as a separate BIP, now it's just an extension of bip54)

git-subtree-dir: bip-0374/secp256k1lab git-subtree-split: 44dc4bd893b8f03e621585e3bf255253e0e0fbfb

…secp256k1lab'

This approach is incompatible with the sys.path extension approach in the next commit which is used to to find the vendored copy of secp256k1lab, so use __file__ instead which works as well.

…alent 12 byte ASCII message types

BIP346: OP_TXHASH

BIP 434: Peer Feature Negotiation

bip-coinbase-fields-bip54.md

darosior

One overall conceptual question i have is whether to mandate that nVersion MUST be set to a specific value given by the server when pools actively use it to transmit some job metadata to hashers. cc @average-gary maybe you have an opinion here

bip-coinbase-fields-bip54.md

darosior · 2026-01-27T17:44:27Z

bip-coinbase-fields-bip54.md

+The `coinbase_sequence` field specifies a value that MUST be used
+for the coinbase transaction input's `nSequence` field.[^sequence]


This is inconsistent with the locktime field for the same reason as nVersion but also because it is given meaning by BIP 54.

See the trade-off comment below: #1 (comment)

Unless miners are currently using this for something, which we should investigate, I'd rather make it safe for future soft forks.

If there's no miner use case right now, but they find one in the future, one can add a new field that adds bit flag, which then takes precedence over coinbase_sequence. Pending such a use case, that seems like needless complexity.

bip-coinbase-fields-bip54.md

darosior · 2026-01-27T17:45:17Z

bip-coinbase-fields-bip54.md

+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


Maybe a broader sentence "in case they are given meaning in the future, for instance with ..."?

darosior · 2026-01-27T17:48:49Z

bip-coinbase-fields-bip54.md

+    The `nLockTime` field could potentially be used as an `extraNonce`, which
+    downstream software may need to roll. However, BIP 54 activation would rule
+    out this use case. It requires an `nLockTime` that's interpreted as a height


I don't think this is a valid "use case". As has been discussed at length, it's extremely theoretical. Much more relevant i think would be MARA's and f2pool's actual use of nLockTime for actually useful purposes.

I'll link to discussions for both, although the chart you link to gives me no clue on what these pools are doing.

I don't think this BIP should adjudicate use cases. The question is whether downstream software should be able to modify the field, even for bad reasons, or whether it MUST use the value provided by the node.

The trade-off is that if we say MUST, it will work for any future soft fork, but restricts what miners can do now.

Found a Stack Exchange post that explains the nLockTime use: https://bitcoin.stackexchange.com/a/119370/4948

darosior · 2026-01-27T17:49:33Z

bip-coinbase-fields-bip54.md

+[^sequence]: **Why not use a bit mask?**
+    The only restriction BIP 54 proposes for `nSequence` is to disallow


This seems fairly BIP 54 centric, whereas my understanding this BIP intends to cover forward compatibility more broadly?

Other than BIP54, is there any other proposal with specific rules for this field?

Requiring clients to use nSequence as provided is the most flexible, when it comes to future soft forks.

I don't think so but i think it's good to be as general as possible.

is the most flexible

i agree

Sjors · 2026-01-27T17:54:45Z

~~Regarding nVersion, clients should be allowed to modify:~~

~~the signalling bits; and~~
~~the BIP320 bits~~

~~I'll adjust the text for that.~~

(confused block version and coinbase version)

darosior · 2026-01-27T18:03:03Z

the signalling bits; and

Hmm? Is this mixing up block version and tx version?

Sjors · 2026-01-27T18:13:54Z

Yes, I got those confused.

For all three fields, there's a triangle trade-off:

allow any future soft fork (clients MUST use the field)
allow miners to tweak things (client MAY use the field, enumerate restrictions that miners MUST use)
complexity of the standard and implementation

My general thinking about that trade-off is to:

Allow existing miner use cases at the expense of soft fork flexibility
Prioritize soft fork flexibility otherwise
Keep it simple, since new BIP22 fields can be added to superseede existing ones

BIP-374: vendor secp256k1lab and use it for reference implementation

BIP 324: Clarify equivalence between 1 and 13 byte message types

…type IDs

BIP 324, 434: Specify p2p v2 one-byte identifier for FEATURE message

BIP 434: fix license inconsistency

@murchandamus

…oin#2004) * Add Chaincode Delegation BIP * Update license to BSD-3-Clause and expand blinded signing documentation * Address initial PR comments * Update with BIP number assignment * Fix delegator_sign test vector * Upgrade secp256k1lab and add license file - Upgrade vendored secp256k1lab to commit a265da1 (adds type annotations) - Add COPYING file to satisfy MIT license requirements - Document secp256k1lab commit reference in BIP text * Fix type checker and linter issues in reference implementation - Fix TweakContext to use Scalar types for gacc/tacc - Replace HashFunction enum with Callable type alias - Fix bytearray to bytes conversion in blind_sign - Move imports to top of file - Fix boolean comparison style (use 'not' instead of '== False') - Add proper type annotations and casts for dict handling - Remove unused imports and type ignore comments * Address PR review comments on terminology and clarity - Add intro explaining delegation naming (chain code is delegated, not signing authority) - Reorder terminology to list Delegator before Delegatee - Replace "quorum" with clearer "can co-sign for UTXOs" language - Clarify derivation constraints in terms of delegatee's extended key - Rename "Delegatee Signing" section to "Signing Modes" - Fix "delegatee can apply" to "delegator can produce" (line 112) - Replace undefined "caller" with "delegatee" (line 173) - Clarify "Change outputs" to "Tweaks for change outputs" (line 98) - Add note that message is separate from CCD bundle - Add note on application-specific verification (addresses, amounts) - Add transition sentence clarifying non-concurrent protocol scope * Add changelog entry for 0.1.3 * Fix header: use Authors (plural) for multiple authors * Fix BIP header format for CI compliance - Change Type from 'Standards Track' to 'Specification' (valid type) - Change 'Created' to 'Assigned' (correct field name per BIP format) - Change 'Post-History' to 'Discussion' (recognized field in buildtable.pl) * Apply suggestion from @murchandamus --------- Co-authored-by: Jesse Posner <jesse.posner@gmail.com>

@murchandamus

* Reduced Data Temporary Softfork * BIP-RDTS: update and expand according to PR feedback * BIP-RDTS: minor updates to wording to address feedback * Address PR comments: update Reference Implementation and Deployment * Address PR comments: Clarify deployment name and bit * Address PR comments: Update BIP number, creation date, and README entry * Address @murchandamus X comment: Add activation threshold * Address PR comments: Update to BIP-3; clarify rationale and deployment * Address PR comments: Clarify scriptPubKey limit rationale and LOCKED_IN behavior

Sjors · 2026-02-09T17:42:31Z

I changed the approach to just expanding BIP54. This gets rid of the triangle complexity since inside the BIP54 text we can just assume BIP54 is there.

I'm still including version so we get completeness, but it's marked as SHOULD.

If you want, please take another look and then I'll open it upstream.

darosior · 2026-02-09T17:50:03Z

I don't think this should go in BIP 54. This is purely informational and not going to matter for anyone upgrading their pool on any reasonable timeline, and GBT extensions should have their own BIP (see Segwit for instance)

Sjors · 2026-02-09T18:00:23Z

I don't think the SegWit (only) historical precedent means we have to make it a separate BIP. It was a more complicated extension, including a new transaction format.

Extending BIP54 fits naturally, given the existing text:

We encourage mining pools to update their software to craft coinbase transactions that are forward-compatible with the changes proposed in this BIP.

This text explains how to actually do that.

The above confusion made it clear to me that writing it as an independent BIP gets confusing.

not going to matter for anyone upgrading their pool on any reasonable timeline

If bitcoin/bitcoin#34419 makes it into v31 then pools can start setting these values in a forward compatible manner as soon as its released.

darosior · 2026-02-09T18:55:02Z

Ok, if you insist i guess let's push it upstream for broader consideration and see what others think?

…

On Monday, February 9th, 2026 at 1:02 PM, Sjors Provoost ***@***.***> wrote: Sjors left a comment [(Sjors/bips#1)](#1 (comment)) I don't think the SegWit (only) historical precedent means we have to make it a separate BIP. It was a more complicated extension, including a new transaction format. Extending BIP54 fits naturally, given the existing text: > We encourage mining pools to update their software to craft coinbase transactions that are forward-compatible with the changes proposed in this BIP. This text explains how to actually do that. The above confusion made it clear to me that writing it as an independent BIP gets confusing. > not going to matter for anyone upgrading their pool on any reasonable timeline If [bitcoin/bitcoin#34419](bitcoin/bitcoin#34419) makes it into v31 then pools can start setting these values in a forward compatible manner as soon as its released. — Reply to this email directly, [view it on GitHub](#1 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3FYEFV7SQP4XG24254T4LDDTRAVCNFSM6AAAAACTCCFIE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNZTGEZDGMJRHE). You are receiving this because you commented.Message ID: ***@***.***>

Sjors · 2026-02-09T19:25:42Z

Done in bitcoin#2097

theStack and others added 13 commits January 15, 2026 00:43

Squashed 'bip-0374/secp256k1lab/' content from commit 44dc4bd

3050bb6

git-subtree-dir: bip-0374/secp256k1lab git-subtree-split: 44dc4bd893b8f03e621585e3bf255253e0e0fbfb

Merge commit '3050bb6b25c0c20b62e2fc1a23276a09d50d151b' as 'bip-0374/…

d2ceae1

…secp256k1lab'

BIP-374: avoid using sys.path[0] to find current working directory

4e18ee6

This approach is incompatible with the sys.path extension approach in the next commit which is used to to find the vendored copy of secp256k1lab, so use __file__ instead which works as well.

BIP-374: replace secp256k1.py with vendored copy of secp256k1lab

459d977

BIP-374: use tagged_hash and xor_bytes routines from secp256k1lab

436a3dd

BIP-374: mention secp256k1lab in BIP text

2b7f079

BIP434: p2p feature negotiation

9630c4c

BIP324: Add Version header and Changelog section

48c0f20

Add BIP-346: OP_TXHASH

6a0636d

BIP324: supporting 1 byte message type ids means supporting the equiv…

4c80568

…alent 12 byte ASCII message types

BIP324: define message_length

40e6634

Merge pull request bitcoin#1500 from stevenroose/txhash

4c2f656

BIP346: OP_TXHASH

Merge pull request bitcoin#2076 from ajtowns/202512-p2p-feature

3177af3

BIP 434: Peer Feature Negotiation

Sjors mentioned this pull request Jan 27, 2026

mining: add coinbase locktime and sequence fields to getblocktemplate RPC bitcoin/bitcoin#34419

Open

Sjors force-pushed the coinbase-fields branch 2 times, most recently from ff501b1 to 717db40 Compare January 27, 2026 17:18

Sjors commented Jan 27, 2026

View reviewed changes

bip-coinbase-fields-bip54.md Outdated Show resolved Hide resolved

Sjors commented Jan 27, 2026

View reviewed changes

bip-coinbase-fields-bip54.md Outdated Show resolved Hide resolved

darosior reviewed Jan 27, 2026

View reviewed changes

murchandamus and others added 8 commits January 28, 2026 10:31

Merge pull request bitcoin#2084 from theStack/bip374-vendor-secp256k1lab

e169a61

BIP-374: vendor secp256k1lab and use it for reference implementation

Merge pull request bitcoin#2086 from ajtowns/202512-bip324-shortid-alias

43e3983

BIP 324: Clarify equivalence between 1 and 13 byte message types

BIP 324: Add auxiliary file tracking assignments of one-byte message …

a3370b5

…type IDs

BIP324, BIP183: Add utreexo's p2pv2 message type ids

df1f098

BIP324, BIP434: Assign message type id for "feature" message

a50c0ea

Merge pull request bitcoin#2092 from ajtowns/202601-feature-shortid

29b4812

BIP 324, 434: Specify p2p v2 one-byte identifier for FEATURE message

BIP 434: fix license inconsistency

3709d73

Merge pull request bitcoin#2094 from ajtowns/202601-bip434-copyright

5d0f70a

BIP 434: fix license inconsistency

jurvis and others added 4 commits February 4, 2026 12:58

Escape pipe character in markdown table (bitcoin#2095)

10c7888

bip54: additional coinbase fields for GBT

e70196c

Sjors force-pushed the coinbase-fields branch from 717db40 to e70196c Compare February 9, 2026 17:42

Sjors changed the title ~~Add BIP-xxxx: additional coinbase fields for GBT~~ bip54: additional coinbase fields for GBT Feb 9, 2026

Sjors closed this Feb 9, 2026

Sjors mentioned this pull request Feb 10, 2026

bip54: add coinbase locktime and sequence to GBT bitcoin/bips#2097

Open

		The `coinbase_sequence` field specifies a value that MUST be used
		for the coinbase transaction input's `nSequence` field.[^sequence]

		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

		[^sequence]: Why not use a bit mask?
		The only restriction BIP 54 proposes for `nSequence` is to disallow

Conversation

Sjors commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

darosior left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sjors Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sjors commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

darosior commented Jan 27, 2026

Uh oh!

Sjors commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sjors commented Feb 9, 2026

Uh oh!

darosior commented Feb 9, 2026

Uh oh!

Sjors commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

darosior commented Feb 9, 2026 via email

Uh oh!

Sjors commented Feb 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Sjors commented Jan 27, 2026 •

edited

Loading

Sjors Jan 29, 2026 •

edited

Loading

Sjors commented Jan 27, 2026 •

edited

Loading

Sjors commented Jan 27, 2026 •

edited

Loading

Sjors commented Feb 9, 2026 •

edited

Loading