From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Addressing remaining points on BIP 54
Date: Thu, 29 Jan 2026 20:08:59 -0800 (PST) [thread overview]
Message-ID: <e758af9b-72fc-4fdd-8e07-e1126635780an@googlegroups.com> (raw)
In-Reply-To: <1dd74f45-bd0a-4fd7-bf80-56a3b2a44128@murch.one>
[-- Attachment #1.1: Type: text/plain, Size: 7382 bytes --]
Hi,
> "that giving meaning to the coinbase transaction nLockTime is undesirable"
On the rational of asking the block height to be in the coinbase's
nLocktime,
to enforce coinbase uniqueness in a post-BIP34-implies-BIP30-limit (i.e
height
= 1,983,702), I think there is a point that would be valuable to clarify and
that is not documented in the BIP.
Let's remind the problem solved with BIP 30. Originally, since genesis,
coinbase
and spending transactions identifiers were able to be duplicated. That
means,
accidentally, an ulterior coinbase transaction was able to overwrite an
unspent
coinbase tx. E.g, if you have block N=50 with coinbase tx_id=0xbeef and if
this
transaction is unspent at block=100, a miner could generate a block with
coinbase
tx_id=0xbeef _again_ and erase the coinbase output included in an anterior
block.
With BIP 30, there is now a check at block validation to reject as invalid
any
block posterior to the BIP activation cutoff (March 15, 2012, 00:00 UTC)
[0].
This uniqueness validation has been then enhanced with BIP34, of which the
two
problems it aims to solve was to introduce a network-wide mechanism to
upgrade
blocks and transactions and enforce block and coinbase uniqueness. Solving
the
second problem is a partially overlapping set of the BIP 30 implemented
solution
[1].
However, and what is the motivation for including the block height in the
coinbase
transaction as part of the BIP54 consensus cleanup, there are some pre-BIP34
activation height coinbase transactions of which the BIP34 solution, i.e
requiring
a CSscriptSig to commit to the block height, are violating historically
violating
said solution [2]. Therefore no optimized validation could be done in the
future for
those BIP-34 historical transactions and BIP54, by mandating another
uniqueness
mechanism than the BIP34 one, would allow to get rid off the BIP30 forever.
Problem, and that's where the BIP54 document and its implementation is
silent,
there is the potential issue of historical BIP34-violating coinbase
transactions
(i.e with a CScriptNum[..] = 1,983,702+) where the nLocktime field has a
value
equal or superiror to the "post-BIP54 activation height". While coinbase
finality
has always been enforced, if the coinbase's unique nSequence field is set to
CTxIn::SequenceFinal, the nLocktime should be ignored (see `IsFinal()`'s
code
comment "in which case nLocktime is ignored").
While, I have no checked yet if the behavior always hold on all version of
the code
(it's all `ContextualCheckBlock()`), the only implicit mentioning I'm
seeing of
this problem, is here [3], it doesn't seem it has been very peer reviewed,
less
even said to be documented in the BIP rational or the implementation.
Present coinbase uniqueness implementation asks for the nSequence field to
be
also set to SequenceFinal, but given the goal is coinbase uniqueness (and
not
timelock semantics, as it would be for any other transaction), I don't
believe
it's necessary to set the sequence field to final. And therefore, the
nSequence
field can be preserved as future extranonce (-- while it would be still
worthy
to have a network-wide policy rule to avoid intempestive usage of the
field).
For where encoding the uniqueness of the coinbase and the arguments that
have been raised so far in the thread, I'm still favoring the coinbase over
the additional op_return field, nLocktime is already a mandatory transaction
field so it's more information-theoretic space efficient. As I was raising
in
a previous comment, I don't think there is an additional risk of
cryptoeconomic
kind of attack, where the coinbase time finality could be used, it's already
implicitly possible for all post-BIP34 coinbase transactions.
Best,
Antoine
OTS hash: f4d42a800a2b6672609b48097a25d961840d7b91cfc5e9caffff65ecd7533dd5
[0] bitcoin-inquistion, commit 8d513a0, validation.cpp L2591
[1] bitcoin-inquisition, commit 8d513a0, validation.cpp L4300
[2] bitcoin-inquisition, commit 8d513a0, validation.cpp L2554
[3] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/6
Le Wednesday, January 14, 2026 à 6:59:48 PM UTC, Murch a écrit :
> Ah right, the Merkle root is calculated based on the stripped
> transaction, and therefore AJ’s idea works fine. Nevermind, carry on!
>
> Thanks,
> Murch
>
> On 2026-01-14 07:33, Antoine Poinsot wrote:
> > Thanks everyone for the comments.
> >
> > Sjors, transactions are serialized in modern blocks as described by
> Murch.
> >
> > Murch, for the purpose of computing the Merkle root transactions are
> serialized without witness data.
> >
> > Best,
> > Antoine
> >
> >
> >
> > On Wednesday, January 14th, 2026 at 5:23 AM, Sjors Provoost <
> sj...@sprovoost.nl> wrote:
> >
> >> Hi Murch,
> >>
> >> You're referring to the "serialization with witness data" defined in
> BIP 141.
> >>
> >> But that's not how the transaction is serialised in a block, since the
> witness is
> >> segregated.
> >>
> >>> The witness is committed in a tree that is nested into the block's
> existing
> >> merkle root via the coinbase transaction for the purpose of making this
> BIP
> >> soft fork compatible. A future hard fork can place this tree in its own
> branch.
> >>
> >> As long as the miner doesn't touch the SegWit OP_RETURN , which also
> commits
> >> to the coinbase witness, it can safely use the legacy transaction
> serialisation.
> >>
> >> - Sjors
> >>
> >> [0]
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transaction-id
> >>
> >>> Op 14 jan 2026, om 01:23 heeft Murch mu...@murch.one het volgende
> geschreven:
> >>>
> >>> Hi Sjors,
> >>>
> >>> On 2026-01-08 00:30, Sjors Provoost wrote:
> >>>
> >>>> 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.
> >>>> I can’t access Delving right now to read AJ’s comment, but a small
> nit on the idea of using an additional output: BIP 141 requires coinbase
> transaction inputs to have a 32-byte witness. Since the witness section
> follows the outputs in the serialization, the bytes before the `nLocktime`
> in a coinbase transaction are the witness of the coinbase input, not the
> last output script.
> >>> -Murch
> >> --
> >> 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+...@googlegroups.com.
> >> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/1B807731-DC2A-4E59-B462-5C210EF1FB73%40sprovoost.nl
> .
>
--
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/e758af9b-72fc-4fdd-8e07-e1126635780an%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9237 bytes --]
next prev parent reply other threads:[~2026-01-30 4:13 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
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 [this message]
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=e758af9b-72fc-4fdd-8e07-e1126635780an@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