* [bitcoindev] Addressing remaining points on BIP 54
@ 2025-12-30 15:59 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-01-08 4:29 ` [bitcoindev] " Antoine Riard
0 siblings, 1 reply; 7+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-12-30 15:59 UTC (permalink / raw)
To: Bitcoin Development Mailing List
Hi everyone,
Some previously raised points regarding BIP 54 have come up again recently, and
i would like to address them here for the record.
The first one is Luke Dashjr's comment [0] that giving meaning to the coinbase
transaction nLockTime is undesirable as it's the ideal position for an
extranonce. But this extranonce only enables a theoretical optimisation for a
non-bottleneck operation: saving an ASIC controller one SHA256 of the coinbase
transaction. Besides, committing to block height in nLockTime is the most
elegant way to guarantee coinbase transaction uniqueness without relying on
non-portable BIP 30 validation. The field is intended for this purpose and
timelock validation 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 [1].
The second one is Jeremy Rubin's comment [2] that we may want to keep 64-byte
transactions, that the validity "seam" this introduces may bring unforeseen
complexity [3] in the design of smart contracts, and that it might be preferable
to introduce a whole new (sparse) Merkle tree instead. But as long as Bitcoin
remains remotely similar to today, any transaction that does not burn funds will
serialize as more than 64 witness-stripped bytes. This is valid regardless of
where the transaction is crafted. Not burning funds is already a concern when
designing smart contracts: as long as this is covered, invalidating 64-byte
transactions does not introduce an additional edge case. Moreover, the sparse
Merkle tree suggestion would be a major change to a core protocol component,
with far-reaching implications. Such a "soft" fork would blind unupgraded nodes,
not only to others' transaction signatures like with Segwit, but to the entirety
of the transaction traffic. This is not the right tradeoff.
I certainly agree that introducing an explicit restriction on a specific
transaction size is inelegant, and i'm partial to arguments about unforeseen
complexity. But when the alternatives are leaving a notorious footgun to
upper-layer developers [4], or making a far more invasive change that
effectively mandates an extension block, this is pragmatically the least bad
solution.
Antoine Poinsot
[0]: Initially raised on the PR to the BIPs repository, but the latest iteration
is in response to my recent email to the Bitcoin mining development mailing list.
See here https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk/m/RBT_LBWQAgAJ
and the thread thereafter.
[1]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/26
[2]: To the best of my knowledge, Jeremy has not published a description of his
proposal. So i'm basing my response on this interview: https://youtu.be/FNKipXl5DTY?t=769.
[3]: An argument previously raised by Eric Voskuil and weighed in the Consensus
Cleanup's Delving thread. See this comment for an attempt at summarizing the
discussion up to that point: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41
[4]: Even the BitVM bridge developers overlooked the need for implementing a
mitigation for this (https://github.com/BitVM/BitVM/issues/285).
--
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/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [bitcoindev] Re: Addressing remaining points on BIP 54
2025-12-30 15:59 [bitcoindev] Addressing remaining points on BIP 54 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2026-01-08 4:29 ` Antoine Riard
2026-01-08 8:30 ` [bitcoindev] " Sjors Provoost
0 siblings, 1 reply; 7+ messages in thread
From: Antoine Riard @ 2026-01-08 4:29 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9807 bytes --]
Hello Poinsot,
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 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.
Now, there could be an argument ecosystem-wise to let the nLocktime free,
as who say speed advantage say less energy consumed network-wide (-- but
isn't that a better outcome to maximize the energy burnt network-wide, even
if it's probabilistic ?).
One alternative design would be to store the height commitment in the
commitment extension introduced by BIP141 [1]. In my understanding, as
it has been pointed out by other minds in the design process about the
actual proposal to put the height commitment in the nLocktime field,
in the eventuality of more than 1 commitment being introduced, a naive
design would come with the burden for non-upgraded nodes to have data
availability to all the merkle path to validate a specific soft-forked
commitment. So a node could not just implement consensus validation rules
for SF #2, without getting the merkle tree data for SF #1.
It doesn't sound that this concern could be alleviated by making the
"witness reserved value", a slot vectors of commitments (e.g
type-length-value),
rather than a merkle tree, if you don't know the meaning of a commitment,
there is no need to fetch over p2p the undefined data, just jump to the
next slot. While indeed, such design would deserve better precision, I'm
thinking it could be another option about where to fit the height
commitment.
On the downside, as it has been pointed too before, it would render the
validation done by embedded signers more complicated, as one would have
to give the header + merkle proof for the coinbase tx inclusion + the
coinase
tx + the witness reserved value commitment + the field in itself. Now,
those embedded signers, for the most sophisticated one e.g validating
lighting channels, due to space constraints, are only validating a subset
of the consensus rules (e.g it doesn't validate the lack of inflation).
So it's unclear to me, that you would strongly clear about validating
the height commitment of the coinbase tx (ensuring the lineage of the
utxo down to your smart contract is sane ?).
An alternative can be to split the u32 nLocktime field in a u24 | u8, with
the u8 field being reserved as an extranonce. An u24 would waive the problem
for few more hundreds of years. So it would be a 40-bit total nonce, made
of a header's nonce + 8 bits nonce. I've not looked into historical blocks
to see what is the extranonce size used in the scriptSig in average.
About the second concern, i.e Jeremy / Eric's one, i.e the risks of
creating a validity "seam" that might introduces unforeseen complexity
in the design of smart contracts. Made the point w.r.t to the 2500 new
sigops limit for legacy tx, but the 64-byte limit size comes with a corner
case, when you're burning funds as additional fees to bump the confirmation
of a time-sensitive tx. Post-BIP54, that means any tx smart contract
toolchain
has to be updated to rule out this tx size (e.g for lightning, at
`closing_signed`
processing).
While indeed, not ruling out the 64-byte case might be only a benign effect,
evluating when you should do it or not ask for a lot of inner know-how from
the PoV of the smart contract toolchain developer. And this is not something
necessarily done once for all, the level of adversarial collaborative tx
malleability that can be achieved by the counterparty can be silently call
to re-evaluation e.g when you're upgrading your protocol form using p2wsh
to p2tr where the signature size changes.
Anyway, my thinking is that a fix long block validation time is a really
must
have, fixes for difficulty adjustment exploits is also very good to have
(what
was Vertcoin that got exploited on this ?), I'm more skeptical on the
merkle tree
malleability fix (for protocols using SPV proofs, it can be mitigated by
additional
check within their toolchain) and for the fix of duplicate coinbase
transactions,
the fix design could be improved.
As I echoed previously, we can still assign a deployment bit to each
proposed fix,
while it's very obviously more coordination work ecosystem-wise in the
hypothesis
of multiple distincts activations, this also let more room to get in
earlier the
consensus cleanup more serious. Not a hill I'm ready to die on, but IMHO
separating
the consensus changes in 4 distinct proposals is better development and
deployment
practice (-- if social consensus is gathered to have all the fixes in one
deployment
we can still have one signaling bit and activation sequence).
Best,
Riard
OTS hash: 808f61fd6438ac7a9e4a2c07a2665e6e7dffb7f831897f0dcbb8134cffad5d0b
[0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[1] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
[2]
https://gnusha.org/pi/bitcoindev/aa916637-befa-795a-caa1-e5ad50ce63c8@electrum.org/
Le jeudi 1 janvier 2026 à 14:33:36 UTC, Antoine Poinsot a écrit :
> Hi everyone,
>
> Some previously raised points regarding BIP 54 have come up again
> recently, and
> i would like to address them here for the record.
>
> The first one is Luke Dashjr's comment [0] that giving meaning to the
> coinbase
> transaction nLockTime is undesirable as it's the ideal position for an
> extranonce. But this extranonce only enables a theoretical optimisation
> for a
> non-bottleneck operation: saving an ASIC controller one SHA256 of the
> coinbase
> transaction. Besides, committing to block height in nLockTime is the most
> elegant way to guarantee coinbase transaction uniqueness without relying on
> non-portable BIP 30 validation. The field is intended for this purpose and
> timelock validation 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 [1].
>
> The second one is Jeremy Rubin's comment [2] that we may want to keep
> 64-byte
> transactions, that the validity "seam" this introduces may bring unforeseen
> complexity [3] in the design of smart contracts, and that it might be
> preferable
> to introduce a whole new (sparse) Merkle tree instead. But as long as
> Bitcoin
> remains remotely similar to today, any transaction that does not burn
> funds will
> serialize as more than 64 witness-stripped bytes. This is valid regardless
> of
> where the transaction is crafted. Not burning funds is already a concern
> when
> designing smart contracts: as long as this is covered, invalidating 64-byte
> transactions does not introduce an additional edge case. Moreover, the
> sparse
> Merkle tree suggestion would be a major change to a core protocol
> component,
> with far-reaching implications. Such a "soft" fork would blind unupgraded
> nodes,
> not only to others' transaction signatures like with Segwit, but to the
> entirety
> of the transaction traffic. This is not the right tradeoff.
>
> I certainly agree that introducing an explicit restriction on a specific
> transaction size is inelegant, and i'm partial to arguments about
> unforeseen
> complexity. But when the alternatives are leaving a notorious footgun to
> upper-layer developers [4], or making a far more invasive change that
> effectively mandates an extension block, this is pragmatically the least
> bad
> solution.
>
> Antoine Poinsot
>
>
> [0]: Initially raised on the PR to the BIPs repository, but the latest
> iteration
> is in response to my recent email to the Bitcoin mining development
> mailing list.
> See here
> https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk/m/RBT_LBWQAgAJ
> and the thread thereafter.
> [1]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/26
> [2]: To the best of my knowledge, Jeremy has not published a description
> of his
> proposal. So i'm basing my response on this interview:
> https://youtu.be/FNKipXl5DTY?t=769.
> [3]: An argument previously raised by Eric Voskuil and weighed in the
> Consensus
> Cleanup's Delving thread. See this comment for an attempt at summarizing
> the
> discussion up to that point:
> https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41
> [4]: Even the BitVM bridge developers overlooked the need for implementing
> a
> mitigation for this (https://github.com/BitVM/BitVM/issues/285).
>
--
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/05f5b0ee-b487-4733-9860-ac0705b6b901n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 12184 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Addressing remaining points on BIP 54
2026-01-08 4:29 ` [bitcoindev] " Antoine Riard
@ 2026-01-08 8:30 ` Sjors Provoost
2026-01-08 16:36 ` Matt Corallo
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Sjors Provoost @ 2026-01-08 8:30 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Development Mailing List, Antoine Poinsot
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
--
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/9C946151-D6DD-4CB7-B524-15FD9F625D9D%40sprovoost.nl.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Addressing remaining points on BIP 54
2026-01-08 8:30 ` [bitcoindev] " Sjors Provoost
@ 2026-01-08 16:36 ` Matt Corallo
2026-01-13 2:16 ` Antoine Riard
2026-01-08 16:40 ` Matt Corallo
2026-01-13 1:49 ` Antoine Riard
2 siblings, 1 reply; 7+ messages in thread
From: Matt Corallo @ 2026-01-08 16:36 UTC (permalink / raw)
To: Sjors Provoost, Antoine Riard
Cc: Bitcoin Development Mailing List, Antoine Poinsot
On 1/8/26 3:30 AM, Sjors Provoost wrote:
> 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.
Assuming some future change to stratum v1/v2 to allow for this (which I think is basically a "never
going to happen"), its worth noting that you can't just roll it for free. Its already the case that
nLockTime has consensus meaning on the coinbase transaction - its enforced like any other block. So
there's relatively little rolling you can do until you get to the current block height and have to
go do something else (I imagine this is why its not been used for this purpose in the past, at least
in part). So the ASIC actually has to understand quite a bit to roll this.
Instead, in practice, ASICs (or their controllers) roll nTime, which is even better cause its in the
header and you know you can ~always roll it once a second. Then rolling a nonce in the coinbase is
easy cause you can just do it in the controller and get plenty of headroom on the ASIC itself with
nTime and a few midstates.
> 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
>
--
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/33ffd6c4-6395-4f6c-a6e8-8b43220cdb00%40mattcorallo.com.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Addressing remaining points on BIP 54
2026-01-08 8:30 ` [bitcoindev] " Sjors Provoost
2026-01-08 16:36 ` Matt Corallo
@ 2026-01-08 16:40 ` Matt Corallo
2026-01-13 1:49 ` Antoine Riard
2 siblings, 0 replies; 7+ messages in thread
From: Matt Corallo @ 2026-01-08 16:40 UTC (permalink / raw)
To: Sjors Provoost, Antoine Riard
Cc: Bitcoin Development Mailing List, Antoine Poinsot
On 1/8/26 3:30 AM, Sjors Provoost wrote:
> 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.
Oops, missed this part. Honestly we should just reserve another 8 bits out of the version for
rolling. 8 bits for signaling is more than enough, and 72PH/2 aught to be enough for a relatively
large ASIC for quite a while :). Then this entire rolling discussion nearly entirely goes away.
--
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/f68d7c20-5119-4159-8e42-f7c10597a789%40mattcorallo.com.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Addressing remaining points on BIP 54
2026-01-08 8:30 ` [bitcoindev] " Sjors Provoost
2026-01-08 16:36 ` Matt Corallo
2026-01-08 16:40 ` Matt Corallo
@ 2026-01-13 1:49 ` Antoine Riard
2 siblings, 0 replies; 7+ messages in thread
From: Antoine Riard @ 2026-01-13 1:49 UTC (permalink / raw)
To: Sjors Provoost; +Cc: Bitcoin Development Mailing List, Antoine Poinsot
[-- Attachment #1: Type: text/plain, Size: 6653 bytes --]
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
--
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/CALZpt%2BFyPWsbvNOo3jpSoBR08a-LXoZi40yaP5VFEaKm%3DNYRPw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8301 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Addressing remaining points on BIP 54
2026-01-08 16:36 ` Matt Corallo
@ 2026-01-13 2:16 ` Antoine Riard
0 siblings, 0 replies; 7+ messages in thread
From: Antoine Riard @ 2026-01-13 2:16 UTC (permalink / raw)
To: Matt Corallo
Cc: Sjors Provoost, Bitcoin Development Mailing List, Antoine Poinsot
[-- Attachment #1: Type: text/plain, Size: 6440 bytes --]
Hi Corallo,
> Assuming some future change to stratum v1/v2 to allow for this (which I
think is basically a "never
> going to happen"), its worth noting that you can't just roll it for free.
This is not like there have been a multitude of pooling protocols deployed
in the past, all with
their awful long-polling mechanisms and other tricks. Saying we should only
consider stratum
v1/v2 in matters of consensus-design it can be a bit blindsighted imho. As
of today block
height, considering the situation where it's height-based locktime, that
would be 19-bit
that you could use as an extranonce, if my measurements are correct.
On the other hand, making the coinbase transaction with an always valid
coinbase's nLocktime
transaction, this opens the door in terms of off-chain protocols and
use-case design (e.g
proof-of-work swap), where now you can use the consensus mandatory check of
the coinbase
nLocktime's field as a novel building block primitive.
Best,
Antoine
OTS hash: 45f28303770b376e2ae8f9e0072ae236d2b42aa4c84036f87ec9903a74a385b3
Le jeu. 8 janv. 2026 à 16:36, Matt Corallo <lf-lists@mattcorallo•com> a
écrit :
>
>
> On 1/8/26 3:30 AM, Sjors Provoost wrote:
> > 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.
>
> Assuming some future change to stratum v1/v2 to allow for this (which I
> think is basically a "never
> going to happen"), its worth noting that you can't just roll it for free.
> Its already the case that
> nLockTime has consensus meaning on the coinbase transaction - its enforced
> like any other block. So
> there's relatively little rolling you can do until you get to the current
> block height and have to
> go do something else (I imagine this is why its not been used for this
> purpose in the past, at least
> in part). So the ASIC actually has to understand quite a bit to roll this.
>
> Instead, in practice, ASICs (or their controllers) roll nTime, which is
> even better cause its in the
> header and you know you can ~always roll it once a second. Then rolling a
> nonce in the coinbase is
> easy cause you can just do it in the controller and get plenty of headroom
> on the ASIC itself with
> nTime and a few midstates.
>
> > 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
> >
>
>
--
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/CALZpt%2BFf_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8276 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-01-13 2:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-30 15:59 [bitcoindev] Addressing remaining points on BIP 54 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-01-08 4:29 ` [bitcoindev] " Antoine Riard
2026-01-08 8:30 ` [bitcoindev] " Sjors Provoost
2026-01-08 16:36 ` Matt Corallo
2026-01-13 2:16 ` Antoine Riard
2026-01-08 16:40 ` Matt Corallo
2026-01-13 1:49 ` Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox