Hi Sjors,

Thanks for the reminder that the coinbase transaction has a 100 bytes
limit, checked IsCoinbase(), but I didn't CheckTransaction() again. So with
a 100 bytes limit, there are still 2^100 extra permutations in addition to the
128 bits already available from the nonce, and the bits from the version fields.

It is true that the coinbase nLocktime is a fixed-size field, so an ASIC can
roll it without having it ot understand anything about serialization, while on
the other hand the scriptSig is as you're noting variable-length (well you can
make assumptions on the var_int fixed-size). I don't think that that whatever
your ASIC design, the chip has to be aware of the serialization subtleties,
this can be done at the proxy-level, and you just feed an unified iterable
bits field (version + scriptSig + coinbase, whatever you use as an extranonce).

I see the idea of appending a 0-sat OP_RETURN output with padding so a 4-byte
nonce is fitting in the data payload of the OP_RETURN. But I don't see how
you avoid the unserialization problem for the proxy of knowing the OP_RETURN
data payload selected size (--I guess register loads and CPU cycles saved
at the architecture levels for the unser buffer mem allocation can be wins
for the proxy). So it might be easier to implement, but not necessarily faster.

Never built an ASIC, but to have studied instruction level architecture, if you
wish optimal performance the question starts to be the size of you're high-level
cache (the ones the nearest of your roll-and-hash-logic) and what is the byte-length
words those caches are working on. Unless you're iterating on 4 MB words fractional
power of 2 of it, but I don't think so.

I'm not aware this behaviour is done in the wild, but in theory if you can
serialize / unserialize on fixed-size data fields for the proxy, it's faster
(just one less one memory allocator call...).

Without digging more on the necessities for current 280 TH/s, this can be fine for
now to just roll the nVersion header field which is a fixed-size too, though I do think
Luke's concern of letting the coinbase as a reserved field for now is not without ground
(of course the nLocktime can be valid today, but what is the worthiness as the nSequence
can be set to disable it, i.e IsFinal()'s semantic).

Best,
Antoine
OTS hash: 6c1f83a60642ef43c911dd57b4b9aaf084cf80445d0af72b1f92f910581f6ead

Le jeu. 8 janv. 2026 à 08:30, Sjors Provoost <sjors@sprovoost.nl> a écrit :

Hello Riard,

> Thanks for the update. If I'm understanding correctly Luke's concern,
> currently the coinbase's scriptSig is used to store an extranonce. One
> has to observe first there is no consensus limit on the size of a
> transaction, which holds for the coinbase tx too, a fortiori there is
> no limit on the extranonce size a miner could fit in the scriptSig.

The coinbase scriptSig is limited to 100 bytes [0]. Some speculation as to
why [1].

The main issue I see is complexity of implementation. The nLockTime is always
the last 4 bytes of a transaction, so an ASIC can roll it without having to
understand anything about serialisation.

The scriptSig OTOH is variable length, so it needs to read the length byte in
order to figure out which 4 bytes are at the end. The pool or proxy then also
needs to ensure those 4 bytes are pre-initialised*.

The approach suggested by Towns [4] of appending a 0-sat OP_RETURN output with
padding so a 4-byte nonce lands in the final 64-byte SHA256 chunk is probably
better, but not because like nLockTime it has a small hashing midstate
benefit. It's easier to implement.

Compared to varying the end of the scriptSig, this can be easier for an ASIC
because it can update a fixed 4-byte field at a known offset from the end,
rather than having to parse variable-length fields (notably the scriptSig
length) to locate the bytes to roll.

I think that extra complexity is doable and justifiable, but I've never built an ASIC.

Note that today Stratum v1 simply splits the scriptSig [5] into two parts, as does
Stratum v2 [3], but presumably that's all done by the control board and it makes
sense to want to push rolling functionally into the ASIC silicon, where even
simple concatenation might be too involved - but updating bytes at known
positions is easy.

> The point being made is that the nLocktime field of the coinbase
> transaction could be used as a more efficient extra nonce due to
> the positional location of nLocktime in a serialized coinbase being
> one of the latest message block to be processed [0].
>
> Nothing prevent a miner in already doing this and draw a speed advantage
> from the diminished computational work. I have not looked into CGminer code
> or one of its derivative forks, if there is an implemented option to do that,
> but yes there could be non-published existing mining firmware doing it. IIUC,
> BIP54 would nullify this theoretical "speed advantage" for all miners.

I don't think there's currently a speed advantage, so I wouldn't expect to observe
this behaviour in the wild just yet. The combination of rolling nVersion
(BIP310) [2] and updating nTime every second, works fine up to 280 TH/s.

Beyond that an ASIC will need to touch the coinbase.

- Sjors

[0] https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L47-L51
[1] https://bitcoin.stackexchange.com/questions/35455/why-bother-having-limitations-on-bitcoin-coinbase-transaction-scriptsigs
[2] https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki
[3] https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#511-standard-job
[4] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=sjors
[5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify

* = otherwise the ASIC needs to know how to extend it, know that it can't be
more than 100 bytes, and that it can't touch the BIP34 part, or really any
subsequent bytes that a future soft fork might constrain