Call for mining pools to make their coinbase transactions compatible with BIP 54

[Antoine Poinsot]

Dear miners,

Exactly a year ago i reached out to this mailing list regarding the Consensus Cleanup effort [^0]. I was exploring whether, from the various ways of preventing future coinbase transactions duplicate, some made things easier for miners.

Based on the feedback i received both here and elsewhere we decided to go for the cleaner fix, which was eventually specified as part of BIP 54 earlier this year. The new restriction introduced on coinbase transactions is the following:

The coinbase transaction's nLockTime field must be set to the height of the block minus 1 and its nSequence field must not be equal to 0xffffffff.

I am now reaching out to ask mining pools to create coinbase transactions compatible with this new restriction, in order to make sure to not run the risk of creating an invalid block should this soft fork be considered for activation.

As an example, Bitcoin Core has been creating compatible coinbase transactions since version 29.0 [^1] for use internally and to serve through the mining IPC interface (notably used by Sjors' experimental Stratum v2 template provider [^2]).

I want to highlight this is a request for mining pools to create forward-compatible coinbase transactions, not a call for activation of the soft fork. Those are two separate things, and the latter heavily depends on the former.

Best,
Antoine Poinsot

[^0]: https://groups.google.com/g/bitcoinminingdev/c/qyrPzU1WKSI

[^1]: see PR https://github.com/bitcoin/bitcoin/pull/32155

[^2]: https://github.com/stratum-mining/sv2-tp

[Luke Dashjr]

NACK. The lock time is the ideal position for an extra nonce and should not be burned.

[Antoine Poinsot]

Luke,

Committing to the block height in the lock time field of coinbase transactions is the most elegant
way to guarantee coinbase transactions uniqueness without relying on non-portable BIP 30 validation.
The field is intended to carry a block height, and is already consensus enforced, which neatly
guarantees historical uniqueness. Furthermore, it makes it possible to extract the block height from
the coinbase transaction without having to parse Script, and enables constant-time proofs of block
height [0].

While theoretically it's true that using the coinbase nLockTime as an extranonce could save an ASIC
controller about one sha256 of the coinbase transaction, it is not currently a bottleneck and
similar efficiency gains can be achieved through other means.

Therefore, as already discussed [1], it does not appear to be a worthwile tradeoff. If you could
explain in more details how you envision using it and what the concrete gains would be, that might
help clarify your perspective.

Antoine Poinsot

[0]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/26
[1]: https://github.com/bitcoin/bips/pull/1800#discussion_r2029450291

[Anthony Towns]

On Wednesday, December 3, 2025 at 12:53:40 AM UTC+10 Antoine Poinsot wrote:

While theoretically it's true that using the coinbase nLockTime as an extranonce could save an ASIC
controller about one sha256 of the coinbase transaction, it is not currently a bottleneck and
similar efficiency gains can be achieved through other means.

You get the exact same efficiency gains just by putting extranonce data in the final output, which is serialized immediately prior to the locktime when calculating the merkle root for the block header.

Cheers,

aj