Hello Poinsot, Thanks for the update. If I'm understanding correctly Luke's concern, currently the coinbase's scriptSig is used to store an extranonce. One has to observe first there is no consensus limit on the size of a transaction, which holds for the coinbase tx too, a fortiori there is no limit on the extranonce size a miner could fit in the scriptSig. The point being made is that the nLocktime field of the coinbase transaction could be used as a more efficient extra nonce due to the positional location of nLocktime in a serialized coinbase being one of the latest message block to be processed [0]. Nothing prevent a miner in already doing this and draw a speed advantage from the diminished computational work. I have not looked into CGminer code or one of its derivative forks, if there is an implemented option to do that, but yes there could be non-published existing mining firmware doing it. IIUC, BIP54 would nullify this theoretical "speed advantage" for all miners. Now, there could be an argument ecosystem-wise to let the nLocktime free, as who say speed advantage say less energy consumed network-wide (-- but isn't that a better outcome to maximize the energy burnt network-wide, even if it's probabilistic ?). One alternative design would be to store the height commitment in the commitment extension introduced by BIP141 [1]. In my understanding, as it has been pointed out by other minds in the design process about the actual proposal to put the height commitment in the nLocktime field, in the eventuality of more than 1 commitment being introduced, a naive design would come with the burden for non-upgraded nodes to have data availability to all the merkle path to validate a specific soft-forked commitment. So a node could not just implement consensus validation rules for SF #2, without getting the merkle tree data for SF #1. It doesn't sound that this concern could be alleviated by making the "witness reserved value", a slot vectors of commitments (e.g type-length-value), rather than a merkle tree, if you don't know the meaning of a commitment, there is no need to fetch over p2p the undefined data, just jump to the next slot. While indeed, such design would deserve better precision, I'm thinking it could be another option about where to fit the height commitment. On the downside, as it has been pointed too before, it would render the validation done by embedded signers more complicated, as one would have to give the header + merkle proof for the coinbase tx inclusion + the coinase tx + the witness reserved value commitment + the field in itself. Now, those embedded signers, for the most sophisticated one e.g validating lighting channels, due to space constraints, are only validating a subset of the consensus rules (e.g it doesn't validate the lack of inflation). So it's unclear to me, that you would strongly clear about validating the height commitment of the coinbase tx (ensuring the lineage of the utxo down to your smart contract is sane ?). An alternative can be to split the u32 nLocktime field in a u24 | u8, with the u8 field being reserved as an extranonce. An u24 would waive the problem for few more hundreds of years. So it would be a 40-bit total nonce, made of a header's nonce + 8 bits nonce. I've not looked into historical blocks to see what is the extranonce size used in the scriptSig in average. About the second concern, i.e Jeremy / Eric's one, i.e the risks of creating a validity "seam" that might introduces unforeseen complexity in the design of smart contracts. Made the point w.r.t to the 2500 new sigops limit for legacy tx, but the 64-byte limit size comes with a corner case, when you're burning funds as additional fees to bump the confirmation of a time-sensitive tx. Post-BIP54, that means any tx smart contract toolchain has to be updated to rule out this tx size (e.g for lightning, at `closing_signed` processing). While indeed, not ruling out the 64-byte case might be only a benign effect, evluating when you should do it or not ask for a lot of inner know-how from the PoV of the smart contract toolchain developer. And this is not something necessarily done once for all, the level of adversarial collaborative tx malleability that can be achieved by the counterparty can be silently call to re-evaluation e.g when you're upgrading your protocol form using p2wsh to p2tr where the signature size changes. Anyway, my thinking is that a fix long block validation time is a really must have, fixes for difficulty adjustment exploits is also very good to have (what was Vertcoin that got exploited on this ?), I'm more skeptical on the merkle tree malleability fix (for protocols using SPV proofs, it can be mitigated by additional check within their toolchain) and for the fix of duplicate coinbase transactions, the fix design could be improved. As I echoed previously, we can still assign a deployment bit to each proposed fix, while it's very obviously more coordination work ecosystem-wise in the hypothesis of multiple distincts activations, this also let more room to get in earlier the consensus cleanup more serious. Not a hill I'm ready to die on, but IMHO separating the consensus changes in 4 distinct proposals is better development and deployment practice (-- if social consensus is gathered to have all the fixes in one deployment we can still have one signaling bit and activation sequence). Best, Riard OTS hash: 808f61fd6438ac7a9e4a2c07a2665e6e7dffb7f831897f0dcbb8134cffad5d0b [0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf [1] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki [2] https://gnusha.org/pi/bitcoindev/aa916637-befa-795a-caa1-e5ad50ce63c8@electrum.org/ Le jeudi 1 janvier 2026 à 14:33:36 UTC, Antoine Poinsot a écrit : > 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/05f5b0ee-b487-4733-9860-ac0705b6b901n%40googlegroups.com.