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’ve 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 to ensure that timelock validation is performed. An nSequence set as final (i.e. equal to 0xffffffff) allows timelock validation to be bypassed. Enforcing timelock validation gives us a context-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’t broken, 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 activation no coinbase transaction can possibly be a duplicate is a useful reduction in complexity. For instance, if BIP 54 activation height ever gets buried in Bitcoin Core, the BIP 30 check could just be disabled past this height instead of having to figure out if we are on a chain that contains the historical BIP 34 activation block hash [3]. Hopefully this clarifies the rationale. I’ll now respond to some 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:00 UTC) [0]. 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. > 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. Your point that the BIP and code documentation could expand on this aspect is well taken. However it is incorrect to say it's only been mentioned implicitly by AJ in this comment. He later suggested to me to also constrain the nSequence in direct communication, and i publicly shared my decision to include his suggestion in the BIP in the Consensus Cleanup thread on Delving [4], the same same thread you point to. In this post i explain the rationale for this decision, which is essentially the reasoning i presented at the beginning of this email. Furthermore, the BIP also explicitly gives this rationale. It reads "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 footnote that goes into greater details about timelock enforcement: "Technically it could be argued a duplicate 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 activation 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 authors are aware of." > 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). 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. Best, Antoine [0]: https://github.com/bitcoin-inquisition/bitcoin/pull/99#discussion_r2636788599 [1]: https://github.com/bitcoin/bips/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://github.com/bitcoin/bitcoin/blob/28d860788286ec31981f5509a8cbe6a9ba4cddc5/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 <[email protected]> wrote: > 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 > > > <[email protected]> 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 [email protected] 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 [email protected]. > > >> 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/e758af9b-72fc-4fdd-8e07-e1126635780an%40googlegroups.com. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0Gc3rCZzaVbzL88b9G3EDjXdayArs8JtirCO2nmmMVLDgbxovIEu7-hhQp0G4wPnEB3YABywEppEFbC-zSudJUiR7HW680kM6LWtHDmp_Hc%3D%40protonmail.com.
