From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 29 Jan 2026 20:13:50 -0800 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vlftF-00069Z-5P for bitcoindev@gnusha.org; Thu, 29 Jan 2026 20:13:50 -0800 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-66308f16ea0sf4388327eaf.0 for ; Thu, 29 Jan 2026 20:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1769746423; x=1770351223; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=wNpemw2Kp24NA+cPb5FLZRRpTR1gmr/xudwc0lrFwmY=; b=MMayt8OO/9g+l4zxrLFBRJ0Y8176wK2d/moqF+lDyY0lRCAdXVcGatJVIR7rd7hlEB fBEVwuuLxYMIF5noPGNq8OhL8jNuAEgF/P1u4I7HvKG07lmbl9dsDgRXiV3Ov9xLDmVU 3Oot/OAWUtF9/0Nv23UnBl8vXJBv2fR8WumkI5m2L19pW9USWlf+G0Yk5gV1eea/d27/ n/nqvmf9nFFVtDqGSp4J/1yJ8b3HhqL+FQfvAdA4hvu6/fH4sD/GZxjMX2Yvl2D8BajU oDVBntDXXGBEtedVwzG0Kg59iwuq1+x7NB6oSarUVr0sVkGbeLYdsrXs08zhUU9URABG 7LfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769746423; x=1770351223; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=wNpemw2Kp24NA+cPb5FLZRRpTR1gmr/xudwc0lrFwmY=; b=eSxjDbG+DvsMnIgaz0vdNzlKz5b+NJQvlt46GCA26NPE4rTarX2aqoM/QaNsLNWGcC hXDnsiqBvBDR6rGqwYsuDWKl9Cy8j+GYHzARLQGhYXLANfTH6ImQptNz64TpYL0J/+Qq LxUx/71xxPOW+0MMQjBbFgG4jGeoHyve1hFjtEtFTOqsOSL6uz7sq0FIM8CvNfawA9V8 GEBxSp58oOY91cN3J8wPbuEgtYn5sJyE3wFyeKlbLLB3A7+zuF4st1+bSUIfcCGvK8rb sEeJq7S8BWZ0JSHr9770ZO3koiKRu0Wsay/8LR24P9M8CmVHyChyvgv1GgPTFw2ZCR+r EAbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769746423; x=1770351223; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=wNpemw2Kp24NA+cPb5FLZRRpTR1gmr/xudwc0lrFwmY=; b=SIfvg01OOhKjNLw1SLtFpuZXxnbkxjIBSkl63SnoeZO7R+R+rYxq8QtU7PpbV/reRD WQX4DV1QXdPOI+E41aoZGU1jSsTYoTVIPrmVnYPB1LzRWT29bc99zClYaQBPfafbWlX6 QzRbL46CqLiK5B280N8QLvHEgudEYIsH2KZ5hEFLtAUKqKbRhy4b112BO/9tkN0zLbRu IP9abu50+rzH2dtYUmKrUFjU4eSWxlqVRRbAxzR9IELTzhIVtsZrPqMc/KbrBnkBYPH1 46R0HghmufcA1iqB29Mp9tBqUqxOsooc5MDHe067j9StYCwAYwBYlh7BWrTf4iZce74V w7fQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVlKD+r3o7g2gDU9NwRvxNxv6hcUxgzW+kovPm2NnGZ173FMCL/dyRrydzdkySbUQH4LoQyp+3XaRVX@gnusha.org X-Gm-Message-State: AOJu0Yy0h4POkYQvm/uhQZvg9mT58K5hzjNxqFtwMJJYmx4E1EI9Pnsc pu4q5fKZ1Si3VBEU/LjP00f0qlgGN1nbOoYUodmMxXrg3HC30v8hk8ft X-Received: by 2002:a05:6820:81c3:b0:65d:829:bad6 with SMTP id 006d021491bc7-6630f3e11d2mr575922eaf.84.1769746422513; Thu, 29 Jan 2026 20:13:42 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+EnyxUHFslZSN17hWSgz6bFc5Jw/Yh3JcOS8/KG1N83aA==" Received: by 2002:a05:6820:1aa0:b0:662:f738:c300 with SMTP id 006d021491bc7-66307c259b2ls722179eaf.0.-pod-prod-08-us; Thu, 29 Jan 2026 20:13:36 -0800 (PST) X-Received: by 2002:a05:6808:1b9a:b0:441:8f74:fce with SMTP id 5614622812f47-45f34d418d4mr837806b6e.59.1769746416004; Thu, 29 Jan 2026 20:13:36 -0800 (PST) Received: by 2002:a05:690c:f8e:b0:790:b655:de0c with SMTP id 00721157ae682-794a118c692ms7b3; Thu, 29 Jan 2026 20:09:00 -0800 (PST) X-Received: by 2002:a05:690c:60c4:b0:794:78ec:4841 with SMTP id 00721157ae682-7949ded795fmr39163207b3.5.1769746139766; Thu, 29 Jan 2026 20:08:59 -0800 (PST) Date: Thu, 29 Jan 2026 20:08:59 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <1dd74f45-bd0a-4fd7-bf80-56a3b2a44128@murch.one> References: <05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com> <9C946151-D6DD-4CB7-B524-15FD9F625D9D@sprovoost.nl> <492f9bba-8a1f-4fa2-8618-98bd564a6178@murch.one> <1B807731-DC2A-4E59-B462-5C210EF1FB73@sprovoost.nl> <_C0iWeaJ-v24dZgcdCnKZKEgK9E493DmpG_-wD1NZnOAuECi97dZpVLuZxkONIfZjTe7km_TWFdSFfmSzVWfJ5Lkz6JTc8JwDOTg9XAInVo=@protonmail.com> <1dd74f45-bd0a-4fd7-bf80-56a3b2a44128@murch.one> Subject: Re: [bitcoindev] Addressing remaining points on BIP 54 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_155772_1231801195.1769746139376" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_155772_1231801195.1769746139376 Content-Type: multipart/alternative; boundary="----=_Part_155773_790492892.1769746139376" ------=_Part_155773_790492892.1769746139376 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 nLocktime, to enforce coinbase uniqueness in a post-BIP34-implies-BIP30-limit (i.e=20 height =3D 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,=20 coinbase and spending transactions identifiers were able to be duplicated. That=20 means, accidentally, an ulterior coinbase transaction was able to overwrite an=20 unspent coinbase tx. E.g, if you have block N=3D50 with coinbase tx_id=3D0xbeef and= if=20 this transaction is unspent at block=3D100, a miner could generate a block with= =20 coinbase tx_id=3D0xbeef _again_ and erase the coinbase output included in an anterio= r=20 block. With BIP 30, there is now a check at block validation to reject as invalid= =20 any block posterior to the BIP activation cutoff (March 15, 2012, 00:00 UTC)=20 [0]. This uniqueness validation has been then enhanced with BIP34, of which the= =20 two problems it aims to solve was to introduce a network-wide mechanism to=20 upgrade blocks and transactions and enforce block and coinbase uniqueness. Solving= =20 the second problem is a partially overlapping set of the BIP 30 implemented=20 solution [1]. However, and what is the motivation for including the block height in the= =20 coinbase transaction as part of the BIP54 consensus cleanup, there are some pre-BIP3= 4 activation height coinbase transactions of which the BIP34 solution, i.e=20 requiring a CSscriptSig to commit to the block height, are violating historically=20 violating said solution [2]. Therefore no optimized validation could be done in the= =20 future for those BIP-34 historical transactions and BIP54, by mandating another=20 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=20 silent, there is the potential issue of historical BIP34-violating coinbase=20 transactions (i.e with a CScriptNum[..] =3D 1,983,702+) where the nLocktime field has a= =20 value equal or superiror to the "post-BIP54 activation height". While coinbase=20 finality has always been enforced, if the coinbase's unique nSequence field is set t= o CTxIn::SequenceFinal, the nLocktime should be ignored (see `IsFinal()`'s=20 code comment "in which case nLocktime is ignored"). While, I have no checked yet if the behavior always hold on all version of= =20 the code (it's all `ContextualCheckBlock()`), the only implicit mentioning I'm=20 seeing of this problem, is here [3], it doesn't seem it has been very peer reviewed,= =20 less even said to be documented in the BIP rational or the implementation. Present coinbase uniqueness implementation asks for the nSequence field to= =20 be also set to SequenceFinal, but given the goal is coinbase uniqueness (and= =20 not timelock semantics, as it would be for any other transaction), I don't=20 believe it's necessary to set the sequence field to final. And therefore, the=20 nSequence field can be preserved as future extranonce (-- while it would be still=20 worthy to have a network-wide policy rule to avoid intempestive usage of the=20 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 transactio= n field so it's more information-theoretic space efficient. As I was raising= =20 in a previous comment, I don't think there is an additional risk of=20 cryptoeconomic kind of attack, where the coinbase time finality could be used, it's alread= y 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 =C3=A0 6:59:48=E2=80=AFPM UTC, Murch a =C3= =A9crit : > Ah right, the Merkle root is calculated based on the stripped=20 > transaction, and therefore AJ=E2=80=99s 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=20 > Murch. > > > > Murch, for the purpose of computing the Merkle root transactions are=20 > 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= =20 > BIP 141. > >> > >> But that's not how the transaction is serialised in a block, since the= =20 > witness is > >> segregated. > >> > >>> The witness is committed in a tree that is nested into the block's=20 > existing > >> merkle root via the coinbase transaction for the purpose of making thi= s=20 > BIP > >> soft fork compatible. A future hard fork can place this tree in its ow= n=20 > branch. > >> > >> As long as the miner doesn't touch the SegWit OP_RETURN , which also= =20 > commits > >> to the coinbase witness, it can safely use the legacy transaction=20 > serialisation. > >> > >> - Sjors > >> > >> [0]=20 > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transactio= n-id > >> > >>> Op 14 jan 2026, om 01:23 heeft Murch mu...@murch.one het volgende=20 > 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= =20 > output with > >>>> padding so a 4-byte nonce lands in the final 64-byte SHA256 chunk is= =20 > probably > >>>> better, but not because like nLockTime it has a small hashing midsta= te > >>>> benefit. It's easier to implement. > >>>> I can=E2=80=99t access Delving right now to read AJ=E2=80=99s commen= t, but a small=20 > nit on the idea of using an additional output: BIP=E2=80=AF141 requires c= oinbase=20 > transaction inputs to have a 32-byte witness. Since the witness section= =20 > follows the outputs in the serialization, the bytes before the `nLocktime= `=20 > in a coinbase transaction are the witness of the coinbase input, not the= =20 > last output script. > >>> -Murch > >> -- > >> You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > >> To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com. > >> To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/1B807731-DC2A-4E59-B462-5C21= 0EF1FB73%40sprovoost.nl > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= e758af9b-72fc-4fdd-8e07-e1126635780an%40googlegroups.com. ------=_Part_155773_790492892.1769746139376 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,

> "that giving meaning to the coinbase transaction nLockT= ime is undesirable"

On the rational of asking the block height t= o be in the coinbase's nLocktime,
to enforce coinbase uniqueness in a = post-BIP34-implies-BIP30-limit (i.e height
=3D 1,983,702), I think the= re is a point that would be valuable to clarify and
that is not docume= nted in the BIP.

Let's remind the problem solved with BIP 30. Or= iginally, since genesis, coinbase
and spending transactions identifier= s were able to be duplicated. That means,
accidentally, an ulterior co= inbase transaction was able to overwrite an unspent
coinbase tx. E.g, = if you have block N=3D50 with coinbase tx_id=3D0xbeef and if this
tran= saction is unspent at block=3D100, a miner could generate a block with coin= base
tx_id=3D0xbeef _again_ and erase the coinbase output included in = an anterior block.

With BIP 30, there is now a check at block va= lidation to reject as invalid any
block posterior to the BIP activatio= n cutoff (March 15, 2012, 00:00 UTC) [0].
This uniqueness validation h= as 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
s= econd problem is a partially overlapping set of the BIP 30 implemented solu= tion
[1].

However, and what is the motivation for including= the block height in the coinbase
transaction as part of the BIP54 con= sensus cleanup, there are some pre-BIP34
activation height coinbase tr= ansactions 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 futur= e for
those BIP-34 historical transactions and BIP54, by mandating ano= ther uniqueness
mechanism than the BIP34 one, would allow to get rid o= ff the BIP30 forever.

Problem, and that's where the BIP54 docume= nt and its implementation is silent,
there is the potential issue of h= istorical BIP34-violating coinbase transactions
(i.e with a CScriptNum= [..] =3D 1,983,702+) where the nLocktime field has a value
equal or su= periror 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").

W= hile, I have no checked yet if the behavior always hold on all version of t= he code
(it's all `ContextualCheckBlock()`), the only implicit mention= ing I'm seeing of
this problem, is here [3], it doesn't seem it has be= en very peer reviewed, less
even said to be documented in the BIP rati= onal or the implementation.

Present coinbase uniqueness implemen= tation asks for the nSequence field to be
also set to SequenceFinal, b= ut given the goal is coinbase uniqueness (and not
timelock semantics, = as it would be for any other transaction), I don't =C2=A0believe
it's = necessary to set the sequence field to final. And therefore, the nSequence<= br />field can be preserved as future extranonce (-- while it would be stil= l worthy
to have a network-wide policy rule to avoid intempestive usag= e of the field).

For where encoding the uniqueness of the coinba= se and the arguments that
have been raised so far in the thread, I'm s= till favoring the coinbase over
the additional op_return field, nLockt= ime is already a mandatory transaction
field so it's more information-= theoretic space efficient. As I was raising in
a previous comment, I d= on't think there is an additional risk of cryptoeconomic
kind of attac= k, where the coinbase time finality could be used, it's already
implic= itly possible for all post-BIP34 coinbase transactions.

Best,Antoine
OTS hash: f4d42a800a2b6672609b48097a25d961840d7b91cfc5e9caf= fff65ecd7533dd5

[0] bitcoin-inquistion, commit 8d513a0, validati= on.cpp L2591
[1] bitcoin-inquisition, commit 8d513a0, validation.cpp L= 4300
[2] bitcoin-inquisition, commit 8d513a0, validation.cpp L2554
[3] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/6
Le Wed= nesday, January 14, 2026 =C3=A0 6:59:48=E2=80=AFPM UTC, Murch a =C3=A9crit= =C2=A0:
Ah ri= ght, the Merkle root is calculated based on the stripped=20
transaction, and therefore AJ=E2=80=99s idea works fine. Nevermind, car= ry 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 b= y Murch.
>
> Murch, for the purpose of computing the Merkle root transactions a= re 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 d= ata" defined in BIP 141.
>>
>> But that's not how the transaction is serialised in a bloc= k, 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 ma= king this BIP
>> soft fork compatible. A future hard fork can place this tree i= n 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 transact= ion serialisation.
>>
>> - Sjors
>>
>> [0] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transacti= on-id
>>
>>> Op 14 jan 2026, om 01:23 heeft Murch mu...@murch.one het v= olgende geschreven:
>>>
>>> Hi Sjors,
>>>
>>> On 2026-01-08 00:30, Sjors Provoost wrote:
>>>
>>>> The approach suggested by Towns [4] of appending a 0-s= at OP_RETURN output with
>>>> padding so a 4-byte nonce lands in the final 64-byte S= HA256 chunk is probably
>>>> better, but not because like nLockTime it has a small = hashing midstate
>>>> benefit. It's easier to implement.
>>>> I can=E2=80=99t access Delving right now to read AJ=E2= =80=99s comment, but a small nit on the idea of using an additional output:= BIP=E2=80=AF141 requires coinbase transaction inputs to have a 32-byte wit= ness. Since the witness section follows the outputs in the serialization, t= he bytes before the `nLocktime` in a coinbase transaction are the witness o= f the coinbase input, not the last output script.
>>> -Murch
>> --
>> You received this message because you are subscribed to the Go= ogle 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%4= 0sprovoost.nl.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/e758af9b-72fc-4fdd-8e07-e1126635780an%40googlegroups.com.
------=_Part_155773_790492892.1769746139376-- ------=_Part_155772_1231801195.1769746139376--