From: Antoine Riard <antoine.riard@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Sjors Provoost <sjors@sprovoost.nl>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
Antoine Poinsot <darosior@protonmail.com>
Subject: Re: [bitcoindev] Addressing remaining points on BIP 54
Date: Tue, 13 Jan 2026 02:16:26 +0000 [thread overview]
Message-ID: <CALZpt+Ff_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw@mail.gmail.com> (raw)
In-Reply-To: <33ffd6c4-6395-4f6c-a6e8-8b43220cdb00@mattcorallo.com>
[-- 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 --]
next prev parent reply other threads:[~2026-01-13 2:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 15:59 '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 [this message]
2026-01-13 16:59 ` Mubarek Juhar
2026-01-08 16:40 ` Matt Corallo
2026-01-13 1:49 ` Antoine Riard
2026-01-14 0:23 ` Murch
2026-01-14 10:15 ` Sjors Provoost
2026-01-14 15:33 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-01-14 18:58 ` Murch
2026-01-30 4:08 ` Antoine Riard
2026-02-05 22:48 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-02-12 3:57 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+Ff_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw@mail.gmail.com \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
--cc=lf-lists@mattcorallo.com \
--cc=sjors@sprovoost.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox