From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Addressing remaining points on BIP 54
Date: Tue, 30 Dec 2025 15:59:49 +0000 [thread overview]
Message-ID: <UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com> (raw)
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.
next reply other threads:[~2026-01-01 14:33 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 [this message]
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-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='UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.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