From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Addressing remaining points on BIP 54
Date: Wed, 7 Jan 2026 20:29:28 -0800 (PST) [thread overview]
Message-ID: <05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com> (raw)
In-Reply-To: <UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com>
[-- 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 --]
next prev parent reply other threads:[~2026-01-08 4:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 15:59 [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-01-08 4:29 ` Antoine Riard [this message]
2026-01-08 8:30 ` Sjors Provoost
2026-01-08 16:36 ` Matt Corallo
2026-01-13 2:16 ` Antoine Riard
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=05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
/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