From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 12 Feb 2026 01:03:15 -0800 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqSbR-00012Q-5g for bitcoindev@gnusha.org; Thu, 12 Feb 2026 01:03:15 -0800 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6630b0a016asf13520281eaf.0 for ; Thu, 12 Feb 2026 01:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770886987; x=1771491787; 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=0oeCgJVXu9gX8kqALoNdcKWHNGwci5h3wvaMjymMbOQ=; b=XYMDlNbT8OJWWbH5beVpr2DlrF4mKf6dSa6OrcxnzslAJwm4DyQ5fpRdD+a6N01r7l zaWC7xta/nTjzLg3J0auC/pU6rhHpyEyAk/BnQqKO672E49U4ociGzz1SSfiFBgQfek1 EPUTLOTUf3Yl6YdvO9gyQB3N5IJclt/zWdiWCriT4FoyUnGM+StDDzwzgwfI/LUnggkp 6rxyo0ME6qzB2Fy94GacH9tnJHHGeLqwBZvSnl3eDO6qUQV7uIwFp0c7+w/WAnpKtYvk RAStvQUAo2Owoi2iCF8QlRvMkXNrbYIyhxs41hRCEPy9m3Kvw7rm8+RA8fcOxSs4UgR+ 8/zw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770886987; x=1771491787; 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=0oeCgJVXu9gX8kqALoNdcKWHNGwci5h3wvaMjymMbOQ=; b=RFYG27XHhnGwdeERxOwlqn5WZuJpNofMxuYm1PRM5mEpQMY17KbTJL8Dir7R1KCAS+ OcIUvwU06mfmqZOeCsyyRzp0zQyQqDK6wNcoj/sBGy6UjXs/KItG9lQ3FUVlOH1x4HFn ZkSJQtyliOXqGEL9ELnG9A4OuQbKE/8z/ufOVGzkESs5Lp/E/vW6hgjxeFbuY0jDmF2u EWiRgrMyrGg352O/RDvEs67mWQNJ74LtvvQ2ZIZ8DeiVt1YUJGIGsPOywVnOSLWEq0Qi y4F/P/f3ytVBGGGjYpXLZJ+YmSO9kxmpjY29pka4ifFAlgoayl9rvorSZEK5cFRcBaRR 9tcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770886987; x=1771491787; 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=0oeCgJVXu9gX8kqALoNdcKWHNGwci5h3wvaMjymMbOQ=; b=iAblKMVl8aVQ+bak77H33YH1x4v0jZ8eqvZ3EnoHk5ZYbmm9OJws+leGtOTDl8T3fz dVfzCrkYcMDBHmvtDU0UbQQpDpta3UcVY1lN8/C9UuFGm7H/Ynw62tXm7LFqHGvNN0mW LwZlBni6ygDR74wtbq9TetiBMe3oOHN39V6JwY08GFajI8VDrmzD5x4rhGf1id/w+OcC yFFGIXXGrZL8fa5Y/SYQOSkriQryJQZ1hbpCIJ1NVOQdPaHmdKCgk85e+1cdRTWAGLmO 6d2Vr0zaFmzT75ZRPM0Z8zIyUCMq9FW5SkJLDbhE6Bk25QFMc64Mah08UxM4A9wGXAiM /ogw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV/Ll7QJo2JD2vxdgpXkrsTKzLm0qupTaGW3dwByH6bCsZ1YLCydAeU7A4j4T8uhay79mVeRyHkIutz@gnusha.org X-Gm-Message-State: AOJu0YyQIZtnHGBRJIiQ0/dgQ1tKxlzR6n+z4+71TTBcPAVzGQA7WkBn 9duAuZGjvcJ/rNXsmSs9vj3MeVqX3t08KH3MAjEGNc3ZVvrDlSTHjvRi X-Received: by 2002:a05:6820:1b08:b0:674:e03e:55e3 with SMTP id 006d021491bc7-675de2f1af3mr553140eaf.81.1770886986551; Thu, 12 Feb 2026 01:03:06 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FB+5zJtaXDWS35RCiBzykF3LrsWDKAFklCG5LNfy4bCg==" Received: by 2002:a05:6820:1626:b0:66a:c0c3:3f25 with SMTP id 006d021491bc7-675d36e569als320239eaf.2.-pod-prod-03-us; Thu, 12 Feb 2026 01:03:01 -0800 (PST) X-Received: by 2002:a05:6808:2205:b0:45e:a2fd:3adb with SMTP id 5614622812f47-4637b6895ecmr1220710b6e.11.1770886981091; Thu, 12 Feb 2026 01:03:01 -0800 (PST) Received: by 2002:a05:690c:3101:b0:796:6bfb:cf56 with SMTP id 00721157ae682-7966bfbd7eems7b3; Wed, 11 Feb 2026 19:57:08 -0800 (PST) X-Received: by 2002:a05:690c:805:b0:795:c78:b648 with SMTP id 00721157ae682-79737692555mr14581667b3.60.1770868627347; Wed, 11 Feb 2026 19:57:07 -0800 (PST) Date: Wed, 11 Feb 2026 19:57:06 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <1922c72f-3288-42b4-b5ad-9757440348c5n@googlegroups.com> In-Reply-To: <0Gc3rCZzaVbzL88b9G3EDjXdayArs8JtirCO2nmmMVLDgbxovIEu7-hhQp0G4wPnEB3YABywEppEFbC-zSudJUiR7HW680kM6LWtHDmp_Hc=@protonmail.com> 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> <0Gc3rCZzaVbzL88b9G3EDjXdayArs8JtirCO2nmmMVLDgbxovIEu7-hhQp0G4wPnEB3YABywEppEFbC-zSudJUiR7HW680kM6LWtHDmp_Hc=@protonmail.com> Subject: Re: [bitcoindev] Addressing remaining points on BIP 54 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_15366_265169485.1770868626979" 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_15366_265169485.1770868626979 Content-Type: multipart/alternative; boundary="----=_Part_15367_166487369.1770868626979" ------=_Part_15367_166487369.1770868626979 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for your insightful additional comments on the BIP rational. > Enforcing timelock validation gives us a context-independent guarantee=20 when > validating a block that no past block in the chain could possibly have=20 had the > same pair of nLockTime and nSequence. I'm getting the general idea of the nlocktime field committing to the current height minus one to ensure coinbase transaction uniquness and avoids to re-activate BIP30 validation post block 1,983,702. Where I'm diverging is on the necessity itself to have to set the nSequence field in any fashion in my understanding due to the check in `ContextualCheckBlock()` (L4312) and the check in `IsFinalTx()` (L4294). The first one is ensuring that nLocktime =3D=3D nHeight - 1 otherwise the coinbase transaction is rejected as invalid. The second one is considering the transaction as final if nLocktime to current nBlockHeight. If a transaction is respecting the first check, i.e nLocktime =3D=3D nHeight - 1, it is implying logicall that nLocktime < nBlockHeight if nHeight =3D=3D nBlockHeight. Unless I'm logically missing something, post BIP54, for the case of the coinbase tx and counter-intuitively _for the case of the coinbase only_, the inspection of its nSequence field to determine it's final is superflous. Said differently, with the new BIP54 check the uniqueness property is coming from a context-dependent check ensuring that a coinbase transaction is always set to the current heigh, and the general validation logic (at least the one of bitcoin core) is ensuring that this context-dependent check is done on a linearly ordered set of block (multiple blocks can have the same ordinal index, but it shouldn't matter for transaction uniqueness). See more comments under. > Technically, as per the code you point to, BIP 30 is enforced from > genesis in Bitcoin Core with the exception of the specific blocks at > height 91,842 and 91,880 in the historical chain." This is correct. The pull request implementing BIP30 only applied after March 15th 2012, and it was latter extended. Somehow, I think it was a hardfork, as in the very hypothetical thermodynamically unlikely scenario where you would take a genesis client and you validate a higher-PoW chain than the historical one, you would get a fork. Doesn't matter for the present discussion. > He later suggested to me to also constrain the nSequence in direct=20 communication, > and i publicly shared my decision to include his suggestion in the BIP in= =20 the > Consensus Cleanup thread on Delving [4], the same same thread you point= =20 to. > In this post i explain the rationale for this decision, which is=20 essentially > the reasoning i presented at the beginning of this email. Thanks for pointing me the exact location, where you mentionned it. Initially read the AJ post of Mar. 2024, where it was first suggested and I think this was the only rational explanation. Quoting your own comment: "Once (and if) the Consensus Cleanup is activated and its activation height buried, this would give us the following property: =E2=80=9CBIP30 validatio= n is=20 never necessary after CC activation height=E2=80=9D. Rephrasing in my own words iiuc, the argument is the following by asking a coinbase to always have its timelock and nsequence not set to final, you ensure that the nLocktime must have been respected at the time (nLocktime < nBlockHeight). Post-BIP54, assuming it's activation height (I'll wawe about the=20 hypothetical situation of hard-fork as you're pointing apparently the 227,835 first=20 blocks=20 have been set with a nLocktime of 0), a pre-BIP54 coinbase transaction coul= d not create a duplicate, therefore BIP 30 validation is unecessary. Okay, at this stage I think I agree with AJ and you on the idea of the=20 rational. However, I still hold the belief the check on the nsequence field is=20 superflous, as with BIP54 you're implementing a context-dependent check that the=20 coinbase transaction nLocktime must be exactly set to the height of the checked=20 block. If this check was assumed to have been enforced since the genesis block, the result would be the same, you're guaranteed to have unique coinbase (there can only be one and only one block valid for a given ordinal height in the blockchain at any time, the blockchain is not a dag or whatever with multiple parents) and BIP 30 should not be necessary again. Again, the block ordering consensus rules are guaranteeing that from the PoV of a let's say a bitcoin core client at any release, there is only _one_ block at a given ordinal height. > I assume you mean default Bitcoin Core mining policy here? Talking about > network wide policy for transactions that don't get relayed is a bit=20 confusing. Yeah a mining policy of which the rational would be to preserve the sanity= =20 of the nSequence field (e.g "nSequence field must be 0"). Coinbase transaction= =20 got relayed by BIP152 message, but technically it's not transaction-relay. That we keep or not the nSequence field BIP54 proposed consensus check, I= =20 think it's of independent interest to keep the nSequence field clean with a=20 legacy rule. BIP141 do not require to have a witness commitment, if there are not witnes= s spends in the block iirc. On the other hand, it's mandatory for the coinbas= e transaction to be present. Here we would got a legacy field present in all coinbase transaction that= =20 could be used to introduce a block-wide commitment structure on 31-bits. Best, Antoine OTS hash: 85b441de80dc914f5b5ef15f2ea8b6f6493755b4b58840e9bf3908781ebdbca8 [0]=20 https://github.com/bitcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1= f952531 =20 Le Thursday, February 5, 2026 =C3=A0 10:52:13=E2=80=AFPM UTC, Antoine Poins= ot a =C3=A9crit : > Hi, > > Thanks for your careful review of our BIP. > > There still appears to be some confusion around the rationale for also=20 > constraining the nSequence, > which suggests the explanation needs to be clearer. I=E2=80=99ve noted th= is in my=20 > collected feedback for the > BIP [0] and will restate the rationale in more detail below. > > The purpose of constraining the nSequence of coinbase transactions is to= =20 > ensure that timelock > validation is performed. An nSequence set as final (i.e. equal to=20 > 0xffffffff) allows timelock > validation to be bypassed. Enforcing timelock validation gives us a=20 > context-independent guarantee > when validating a block that no past block in the chain could possibly=20 > have had the same pair of > nLockTime and nSequence. Therefore, assuming SHA256 isn=E2=80=99t broken,= the txid=20 > of the coinbase > transaction in the block being validated is guaranteed to be unique. > > Of course, we already know that no block pre-BIP 34 activation had its=20 > nLockTime set in the > historical chain [2]. However, being able to state that post-BIP 54=20 > activation no coinbase > transaction can possibly be a duplicate is a useful reduction in=20 > complexity. For instance, if BIP 54 > activation height ever gets buried in Bitcoin Core, the BIP 30 check coul= d=20 > just be disabled past > this height instead of having to figure out if we are on a chain that=20 > contains the historical BIP 34 > activation block hash [3]. > > Hopefully this clarifies the rationale. I=E2=80=99ll now respond to some = specific=20 > points from your email. > > > With BIP 30, there is now a check at block validation to reject as=20 > invalid any > > block posterior to the BIP activation cutoff (March 15, 2012, 00:00 UTC= )=20 > [0]. > > Technically, as per the code you point to, BIP 30 is enforced from genesi= s=20 > in Bitcoin Core with the > exception of the specific blocks at height 91,842 and 91,880 in the=20 > historical chain. > > > the only implicit mentioning I'm seeing of this problem, is here [3], i= t=20 > doesn't seem it has been > > very peer reviewed, less even said to be documented in the BIP rational= =20 > or the implementation. > > Your point that the BIP and code documentation could expand on this aspec= t=20 > is well taken. However it > is incorrect to say it's only been mentioned implicitly by AJ in this=20 > comment. He later suggested to > me to also constrain the nSequence in direct communication, and i publicl= y=20 > shared my decision to > include his suggestion in the BIP in the Consensus Cleanup thread on=20 > Delving [4], the same same > thread you point to. In this post i explain the rationale for this=20 > decision, which is essentially > the reasoning i presented at the beginning of this email. > > Furthermore, the BIP also explicitly gives this rationale. It reads "Ther= e=20 > are multiple ways of > achieving this, but setting and enforcing the timelock for the coinbase= =20 > transaction makes it so all > coinbase transactions past Consensus Cleanup activation could not have=20 > been valid before this height > and therefore cannot be a duplicate." And then it links to a footnote tha= t=20 > goes into greater details > about timelock enforcement: "Technically it could be argued a duplicate= =20 > could in principle always be > possible before block 31,001 when nLockTime enforcement was originally=20 > soft-forked. But treating > coinbase transactions as not having duplicate past Consensus Cleanup=20 > activation would be consistent > for any implementation which enforces nLockTime from the genesis block,= =20 > which is the behaviour > notably of Bitcoin Core but also of all other implementations the authors= =20 > are aware of." > > > And therefore, the nSequence field can be preserved as future extranonc= e=20 > (-- while it would be > > still worthy to have a network-wide policy rule to avoid intempestive= =20 > usage of the field). > > I assume you mean default Bitcoin Core mining policy here? Talking about= =20 > network wide policy for > transactions that don't get relayed is a bit confusing. > > Best, > Antoine > > [0]:=20 > https://github.com/bitcoin-inquisition/bitcoin/pull/99#discussion_r263678= 8599 > [1]: https://github.com/bitcoin/bips/pull/2015#issuecomment-3773345379 > [2]: In fact, the nLockTime of all coinbase transactions in the 227,835= =20 > first blocks in the > historical chain are all set to 0. > [3]:=20 > https://github.com/bitcoin/bitcoin/blob/28d860788286ec31981f5509a8cbe6a9b= a4cddc5/src/validation.cpp#L2391-L2461 > [4]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/79 > > > On Thursday, January 29th, 2026 at 11:13 PM, Antoine Riard < > antoin...@gmail.com> wrote: > > > Hi, > >=20 > > > "that giving meaning to the coinbase transaction nLockTime is=20 > undesirable" > >=20 > > 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 clar= ify=20 > and > > that is not documented in the BIP. > >=20 > > 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=20 > if this > > transaction is unspent at block=3D100, a miner could generate a block w= ith=20 > coinbase > > tx_id=3D0xbeef _again_ and erase the coinbase output included in an=20 > anterior block. > >=20 > > With BIP 30, there is now a check at block validation to reject as=20 > invalid 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= =20 > the 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.=20 > Solving the > > second problem is a partially overlapping set of the BIP 30 implemented= =20 > solution > > [1]. > >=20 > > However, and what is the motivation for including the block height in= =20 > the coinbase > > transaction as part of the BIP54 consensus cleanup, there are some=20 > pre-BIP34 > > 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= =20 > the 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=20 > forever. > >=20 > > 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 ha= s a=20 > value > > equal or superiror to the "post-BIP54 activation height". While coinbas= e=20 > finality > > has always been enforced, if the coinbase's unique nSequence field is= =20 > set to > > CTxIn::SequenceFinal, the nLocktime should be ignored (see `IsFinal()`'= s=20 > code > > comment "in which case nLocktime is ignored"). > >=20 > > While, I have no checked yet if the behavior always hold on all version= =20 > of 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=20 > reviewed, less > > even said to be documented in the BIP rational or the implementation. > >=20 > > Present coinbase uniqueness implementation asks for the nSequence field= =20 > to be > > also set to SequenceFinal, but given the goal is coinbase uniqueness=20 > (and 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). > >=20 > > For where encoding the uniqueness of the coinbase and the arguments tha= t > > have been raised so far in the thread, I'm still favoring the coinbase= =20 > over > > the additional op_return field, nLocktime is already a mandatory=20 > transaction > > field so it's more information-theoretic space efficient. As I was=20 > raising 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=20 > already > > implicitly possible for all post-BIP34 coinbase transactions. > >=20 > > Best, > > Antoine > > OTS hash:=20 > f4d42a800a2b6672609b48097a25d961840d7b91cfc5e9caffff65ecd7533dd5 > >=20 > > [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 : > >=20 > > > Ah right, the Merkle root is calculated based on the stripped > > > transaction, and therefore AJ=E2=80=99s idea works fine. Nevermind, c= arry on! > > >=20 > > > Thanks, > > > Murch > > >=20 > > > 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 ar= e=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= =20 > in BIP 141. > > > >> > > > >> But that's not how the transaction is serialised in a block, since= =20 > the 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= =20 > this BIP > > > >> soft fork compatible. A future hard fork can place this tree in it= s=20 > own branch. > > > >> > > > >> As long as the miner doesn't touch the SegWit OP_RETURN , which=20 > also 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=20 > OP_RETURN output with > > > >>>> padding so a 4-byte nonce lands in the final 64-byte SHA256 chun= k=20 > is probably > > > >>>> better, but not because like nLockTime it has a small hashing=20 > midstate > > > >>>> benefit. It's easier to implement. > > > >>>> I can=E2=80=99t access Delving right now to read AJ=E2=80=99s co= mment, but a=20 > small nit on the idea of using an additional output: BIP=E2=80=AF141 requ= ires=20 > coinbase transaction inputs to have a 32-byte witness. Since the witness= =20 > section follows the outputs in the serialization, the bytes before the=20 > `nLocktime` in a coinbase transaction are the witness of the coinbase=20 > input, not the 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,= =20 > send 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=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/e758af9b-72fc-4fdd-8e07-e112= 6635780an%40googlegroups.com > . > --=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/= 1922c72f-3288-42b4-b5ad-9757440348c5n%40googlegroups.com. ------=_Part_15367_166487369.1770868626979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,

Thanks for your insightful additional comments on the BIP ra= tional.

> Enforcing timelock validation gives us a context-in= dependent guarantee when
> validating a block that no past block in= the chain could possibly have had the
> same pair of nLockTime and= nSequence.

I'm getting the general idea of the nlocktime field = committing to the
current height minus one to ensure coinbase transact= ion uniquness and
avoids to re-activate BIP30 validation post block 1,= 983,702.

Where I'm diverging is on the necessity itself to have = to set the
nSequence field in any fashion in my understanding due to t= he check
in `ContextualCheckBlock()` (L4312) and the check in `IsFinal= Tx()`
(L4294). The first one is ensuring that nLocktime =3D=3D nHeight= - 1
otherwise the coinbase transaction is rejected as invalid. Thesecond one is considering the transaction as final if nLocktime
to = current nBlockHeight.

If a transaction is respecting the first c= heck, i.e nLocktime =3D=3D
nHeight - 1, it is implying logicall that n= Locktime < nBlockHeight
if nHeight =3D=3D nBlockHeight. Unless I'm = logically missing something,
post BIP54, for the case of the coinbase = tx and counter-intuitively
_for the case of the coinbase only_, the in= spection of its nSequence
field to determine it's final is superflous.=

Said differently, with the new BIP54 check the uniqueness prope= rty
is coming from a context-dependent check ensuring that a coinbase<= br />transaction is always set to the current heigh, and the general
v= alidation logic (at least the one of bitcoin core) is ensuring
that th= is context-dependent check is done on a linearly ordered
set of block = (multiple blocks can have the same ordinal index, but
it shouldn't mat= ter for transaction uniqueness).

See more comments under.
<= br />> Technically, as per the code you point to, BIP 30 is enforced fro= m
> genesis in Bitcoin Core with the exception of the specific bloc= ks at
> height 91,842 and 91,880 in the historical chain."
This is correct. The pull request implementing BIP30 only applied after<= br />March 15th 2012, and it was latter extended. Somehow, I think it was a=
hardfork, as in the very hypothetical thermodynamically unlikely scen= ario
where you would take a genesis client and you validate a higher-P= oW chain
than the historical one, you would get a fork.

Doe= sn't matter for the present discussion.

> He later suggested = to me to also constrain the nSequence in direct communication,
> an= d i publicly shared my decision to include his suggestion in the BIP in the=
> Consensus Cleanup thread on Delving [4], the same same thread yo= u point to.
> In this post i explain the rationale for this decisio= n, which is essentially
> the reasoning i presented at the beginnin= g of this email.

Thanks for pointing me the exact location, wher= e you mentionned it.
Initially read the AJ post of Mar. 2024, where it= was first suggested
and I think this was the only rational explanatio= n.

Quoting your own comment:

"Once (and if) the Conse= nsus Cleanup is activated and its activation height
buried, this would= give us the following property: =E2=80=9CBIP30 validation is never
ne= cessary after CC activation height=E2=80=9D.

Rephrasing in my ow= n words iiuc, the argument is the following by asking a
coinbase to al= ways have its timelock and nsequence not set to final, you
ensure that= the nLocktime must have been respected at the time (nLocktime
< nB= lockHeight).

Post-BIP54, assuming it's activation height (I'll w= awe about the hypothetical
situation of hard-fork as you're pointing a= pparently the 227,835 first blocks
have been set with a nLocktime of = 0), a pre-BIP54 coinbase transaction could
not create a duplicate, the= refore BIP 30 validation is unecessary.

Okay, at this stage I th= ink I agree with AJ and you on the idea of the rational.

However= , I still hold the belief the check on the nsequence field is superflous,as with BIP54 you're implementing a context-dependent check that the co= inbase
transaction nLocktime must be exactly set to the height of the = checked block.

If this check was assumed to have been enforced s= ince the genesis block,
the result would be the same, you're guarantee= d to have unique coinbase
(there can only be one and only one block va= lid for a given ordinal height
in the blockchain at any time, the bloc= kchain is not a dag or whatever
with multiple parents) and BIP 30 shou= ld not be necessary again.

Again, the block ordering consensus r= ules are guaranteeing that from
the PoV of a let's say a bitcoin core = client at any release, there is
only _one_ block at a given ordinal he= ight.

> I assume you mean default Bitcoin Core mining policy = here? Talking about
> network wide policy for transactions that don= 't get relayed is a bit confusing.

Yeah a mining policy of which= the rational would be to preserve the sanity of
the nSequence field (= e.g "nSequence field must be 0"). Coinbase transaction got
relayed by = BIP152 message, but technically it's not transaction-relay.

That= we keep or not the nSequence field BIP54 proposed consensus check, I think=
it's of independent interest to keep the nSequence field clean with a= legacy rule.

BIP141 do not require to have a witness commitment= , if there are not witness
spends in the block iirc. On the other hand= , it's mandatory for the coinbase
transaction to be present.

Here we would got a legacy field present in all coinbase transaction that= could
be used to introduce a block-wide commitment structure on 31-bi= ts.

Best,
Antoine
OTS hash: 85b441de80dc914f5b5ef15f2e= a8b6f6493755b4b58840e9bf3908781ebdbca8

[0] https://github.com/bi= tcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531=C2=A0=C2=A0
Le Thursday, February 5, 2026 =C3=A0 10:52:13=E2=80=AFPM UTC, Antoine Poin= sot a =C3=A9crit=C2=A0:
Hi,

Thanks for your careful review of our BIP.

There still appears to be some confusion around the rationale for also = constraining the nSequence,
which suggests the explanation needs to be clearer. I=E2=80=99ve noted = this in my collected feedback for the
BIP [0] and will restate the rationale in more detail below.

The purpose of constraining the nSequence of coinbase transactions is t= o ensure that timelock
validation is performed. An nSequence set as final (i.e. equal to 0xfff= fffff) allows timelock
validation to be bypassed. Enforcing timelock validation gives us a con= text-independent guarantee
when validating a block that no past block in the chain could possibly = have had the same pair of
nLockTime and nSequence. Therefore, assuming SHA256 isn=E2=80=99t broke= n, the txid of the coinbase
transaction in the block being validated is guaranteed to be unique.

Of course, we already know that no block pre-BIP 34 activation had its = nLockTime set in the
historical chain [2]. However, being able to state that post-BIP 54 act= ivation no coinbase
transaction can possibly be a duplicate is a useful reduction in comple= xity. For instance, if BIP 54
activation height ever gets buried in Bitcoin Core, the BIP 30 check co= uld just be disabled past
this height instead of having to figure out if we are on a chain that c= ontains the historical BIP 34
activation block hash [3].

Hopefully this clarifies the rationale. I=E2=80=99ll now respond to som= e specific points from your email.

> 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:0= 0 UTC) [0].

Technically, as per the code you point to, BIP 30 is enforced from gene= sis in Bitcoin Core with the
exception of the specific blocks at height 91,842 and 91,880 in the his= torical chain.

> the only implicit mentioning I'm seeing of this problem, is he= re [3], it doesn't seem it has been
> very peer reviewed, less even said to be documented in the BIP rat= ional or the implementation.

Your point that the BIP and code documentation could expand on this asp= ect is well taken. However it
is incorrect to say it's only been mentioned implicitly by AJ in th= is comment. He later suggested to
me to also constrain the nSequence in direct communication, and i publi= cly shared my decision to
include his suggestion in the BIP in the Consensus Cleanup thread on De= lving [4], the same same
thread you point to. In this post i explain the rationale for this deci= sion, which is essentially
the reasoning i presented at the beginning of this email.

Furthermore, the BIP also explicitly gives this rationale. It reads &qu= ot;There are multiple ways of
achieving this, but setting and enforcing the timelock for the coinbase= transaction makes it so all
coinbase transactions past Consensus Cleanup activation could not have = been valid before this height
and therefore cannot be a duplicate." And then it links to a footn= ote that goes into greater details
about timelock enforcement: "Technically it could be argued a dupl= icate could in principle always be
possible before block 31,001 when nLockTime enforcement was originally = soft-forked. But treating
coinbase transactions as not having duplicate past Consensus Cleanup ac= tivation would be consistent
for any implementation which enforces nLockTime from the genesis block,= which is the behaviour
notably of Bitcoin Core but also of all other implementations the autho= rs are aware of."

> And therefore, the nSequence field can be preserved as future extr= anonce (-- while it would be
> still worthy to have a network-wide policy rule to avoid intempest= ive usage of the field).

I assume you mean default Bitcoin Core mining policy here? Talking abou= t network wide policy for
transactions that don't get relayed is a bit confusing.

Best,
Antoine

[0]: https= ://github.com/bitcoin-inquisition/bitcoin/pull/99#discussion_r2636788599
[1]: https://github.com/bitcoin/bi= ps/pull/2015#issuecomment-3773345379
[2]: In fact, the nLockTime of all coinbase transactions in the 227,835= first blocks in the
historical chain are all set to 0.
[3]: https://gith= ub.com/bitcoin/bitcoin/blob/28d860788286ec31981f5509a8cbe6a9ba4cddc5/src/va= lidation.cpp#L2391-L2461
[4]: https://delvingbitcoin.org/= t/great-consensus-cleanup-revival/710/79


On Thursday, January 29th, 2026 at 11:13 PM, Antoine Riard <antoin...@gmail.com> wrote:

> Hi,
>=20
> > "that giving meaning to the coinbase transaction nLockTi= me is undesirable"
>=20
> On the rational of asking the block height to be in the coinbase&#= 39;s nLocktime,
> to enforce coinbase uniqueness in a post-BIP34-implies-BIP30-limit= (i.e 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.
>=20
> 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 overwri= te an unspent
> coinbase tx. E.g, if you have block N=3D50 with coinbase tx_id=3D0= xbeef and if this
> transaction is unspent at block=3D100, a miner could generate a bl= ock with coinbase
> tx_id=3D0xbeef _again_ and erase the coinbase output included in a= n anterior block.
>=20
> 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:0= 0 UTC) [0].
> This uniqueness validation has been then enhanced with BIP34, of w= hich the two
> problems it aims to solve was to introduce a network-wide mechanis= m to upgrade
> blocks and transactions and enforce block and coinbase uniqueness.= Solving the
> second problem is a partially overlapping set of the BIP 30 implem= ented solution
> [1].
>=20
> 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 solutio= n, i.e requiring
> a CSscriptSig to commit to the block height, are violating histori= cally violating
> said solution [2]. Therefore no optimized validation could be done= in the future for
> those BIP-34 historical transactions and BIP54, by mandating anoth= er uniqueness
> mechanism than the BIP34 one, would allow to get rid off the BIP30= forever.
>=20
> Problem, and that's where the BIP54 document and its implement= ation is silent,
> there is the potential issue of historical BIP34-violating coinbas= e transactions
> (i.e with a CScriptNum[..] =3D 1,983,702+) where the nLocktime fie= ld 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 f= ield is set to
> CTxIn::SequenceFinal, the nLocktime should be ignored (see `IsFina= l()`'s code
> comment "in which case nLocktime is ignored").
>=20
> While, I have no checked yet if the behavior always hold on all ve= rsion of the 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 been very pe= er reviewed, less
> even said to be documented in the BIP rational or the implementati= on.
>=20
> Present coinbase uniqueness implementation asks for the nSequence = field to be
> also set to SequenceFinal, but given the goal is coinbase uniquene= ss (and not
> timelock semantics, as it would be for any other transaction), I d= on't believe
> it's necessary to set the sequence field to final. And therefo= re, 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).
>=20
> For where encoding the uniqueness of the coinbase and the argument= s 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 t= ransaction
> 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.
>=20
> Best,
> Antoine
> OTS hash: f4d42a800a2b6672609b48097a25d961840d7b91cfc5e9caffff65ec= d7533dd5
>=20
> [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.or= g/t/great-consensus-cleanup-revival/710/6
> Le Wednesday, January 14, 2026 =C3=A0 6:59:48=E2=80=AFPM UTC, Murc= h a =C3=A9crit :
>=20
> > Ah right, the Merkle root is calculated based on the stripped
> > transaction, and therefore AJ=E2=80=99s idea works fine. Neve= rmind, carry on!
> >=20
> > Thanks,
> > Murch
> >=20
> > On 2026-01-14 07:33, Antoine Poinsot wrote:
> > > Thanks everyone for the comments.
> > >
> > > Sjors, transactions are serialized in modern blocks as d= escribed by Murch.
> > >
> > > Murch, for the purpose of computing the Merkle root tran= sactions are serialized without witness data.
> > >
> > > Best,
> > > Antoine
> > >
> > >
> > >
> > > On Wednesday, January 14th, 2026 at 5:23 AM, Sjors Provo= ost <sj...@sprovoost.nl&g= t; 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 neste= d into the block's existing
> > >> merkle root via the coinbase transaction for the pur= pose of making this BIP
> > >> soft fork compatible. A future hard fork can place t= his 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 legac= y 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 appen= ding 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 ha= s 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 addition= al output: BIP=E2=80=AF141 requires coinbase transaction inputs to have a 3= 2-byte witness. Since the witness section follows the outputs in the serial= ization, 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 em= ails from it, send an email to b= itcoindev+...@googlegroups.com.
> > >> To view this discussion visit 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 email to bitcoindev+...@= googlegroups.com.
> To view this discussion visit ht= tps://groups.google.com/d/msgid/bitcoindev/e758af9b-72fc-4fdd-8e07-e1126635= 780an%40googlegroups.com.

--
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/1922c72f-3288-42b4-b5ad-9757440348c5n%40googlegroups.com.
------=_Part_15367_166487369.1770868626979-- ------=_Part_15366_265169485.1770868626979--