Bitcoin Development Mailinglist
 help / color / mirror / Atom feed

* [bitcoindev] Addressing remaining points on BIP 54
@ 2025-12-30 15:59 'Antoine Poinsot' via Bitcoin Development Mailing List
  2026-01-08  4:29 ` [bitcoindev] " Antoine Riard
  0 siblings, 1 reply; 15+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-12-30 15:59 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

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/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do%3D%40protonmail.com.


^ permalink raw reply	[flat|nested] 15+ messages in thread

• * [bitcoindev] Re: Addressing remaining points on BIP 54
    2025-12-30 15:59 [bitcoindev] Addressing remaining points on BIP 54 'Antoine Poinsot' via Bitcoin Development Mailing List
  @ 2026-01-08  4:29 ` Antoine Riard
    2026-01-08  8:30   ` [bitcoindev] " Sjors Provoost
    0 siblings, 1 reply; 15+ messages in thread
  From: Antoine Riard @ 2026-01-08  4:29 UTC (permalink / raw)
    To: Bitcoin Development Mailing List
  
  
  [-- Attachment #1.1: Type: text/plain, Size: 9807 bytes --]
  
  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.
  
  [-- Attachment #1.2: Type: text/html, Size: 12184 bytes --]
  
  ^ permalink raw reply	[flat|nested] 15+ messages in thread

• • * Re: [bitcoindev] Addressing remaining points on BIP 54
      2026-01-08  4:29 ` [bitcoindev] " Antoine Riard
    @ 2026-01-08  8:30   ` Sjors Provoost
      2026-01-08 16:36     ` Matt Corallo
                           ` (3 more replies)
      0 siblings, 4 replies; 15+ messages in thread
    From: Sjors Provoost @ 2026-01-08  8:30 UTC (permalink / raw)
      To: Antoine Riard; +Cc: Bitcoin Development Mailing List, Antoine Poinsot
    
    Hello Riard,
    
    > 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 coinbase scriptSig is limited to 100 bytes [0]. Some speculation as to
    why [1].
    
    The main issue I see is complexity of implementation. The nLockTime is always
    the last 4 bytes of a transaction, so an ASIC can roll it without having to
    understand anything about serialisation.
    
    The scriptSig OTOH is variable length, so it needs to read the length byte in
    order to figure out which 4 bytes are at the end. The pool or proxy then also
    needs to ensure those 4 bytes are pre-initialised*.
    
    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.
    
    Compared to varying the end of the scriptSig, this can be easier for an ASIC
    because it can update a fixed 4-byte field at a known offset from the end,
    rather than having to parse variable-length fields (notably the scriptSig
    length) to locate the bytes to roll.
    
    I think that extra complexity is doable and justifiable, but I've never built an ASIC.
    
    Note that today Stratum v1 simply splits the scriptSig [5] into two parts, as does
    Stratum v2 [3], but presumably that's all done by the control board and it makes
    sense to want to push rolling functionally into the ASIC silicon, where even
    simple concatenation might be too involved - but updating bytes at known
    positions is easy.
    
    > 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.
    
    I don't think there's currently a speed advantage, so I wouldn't expect to observe
    this behaviour in the wild just yet. The combination of rolling nVersion
    (BIP310) [2] and updating nTime every second, works fine up to 280 TH/s.
    
    Beyond that an ASIC will need to touch the coinbase.
    
    - Sjors
    
    [0] https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L47-L51
    [1] https://bitcoin.stackexchange.com/questions/35455/why-bother-having-limitations-on-bitcoin-coinbase-transaction-scriptsigs
    [2] https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki
    [3] https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#511-standard-job
    [4] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=sjors
    [5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify
    
    * = otherwise the ASIC needs to know how to extend it, know that it can't be
    more than 100 bytes, and that it can't touch the BIP34 part, or really any
    subsequent bytes that a future soft fork might constrain
    
    -- 
    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/9C946151-D6DD-4CB7-B524-15FD9F625D9D%40sprovoost.nl.
    
    
    ^ permalink raw reply	[flat|nested] 15+ messages in thread

  • • * Re: [bitcoindev] Addressing remaining points on BIP 54
        2026-01-08  8:30   ` [bitcoindev] " Sjors Provoost
      @ 2026-01-08 16:36     ` Matt Corallo
        2026-01-13  2:16       ` Antoine Riard
        2026-01-08 16:40     ` Matt Corallo
                             ` (2 subsequent siblings)
        3 siblings, 1 reply; 15+ messages in thread
      From: Matt Corallo @ 2026-01-08 16:36 UTC (permalink / raw)
        To: Sjors Provoost, Antoine Riard
        Cc: Bitcoin Development Mailing List, Antoine Poinsot
      
      
      
      On 1/8/26 3:30 AM, Sjors Provoost wrote:
      > Hello Riard,
      > 
      >> 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 coinbase scriptSig is limited to 100 bytes [0]. Some speculation as to
      > why [1].
      > 
      > The main issue I see is complexity of implementation. The nLockTime is always
      > the last 4 bytes of a transaction, so an ASIC can roll it without having to
      > understand anything about serialisation.
      
      Assuming some future change to stratum v1/v2 to allow for this (which I think is basically a "never 
      going to happen"), its worth noting that you can't just roll it for free. Its already the case that 
      nLockTime has consensus meaning on the coinbase transaction - its enforced like any other block. So 
      there's relatively little rolling you can do until you get to the current block height and have to 
      go do something else (I imagine this is why its not been used for this purpose in the past, at least 
      in part). So the ASIC actually has to understand quite a bit to roll this.
      
      Instead, in practice, ASICs (or their controllers) roll nTime, which is even better cause its in the 
      header and you know you can ~always roll it once a second. Then rolling a nonce in the coinbase is 
      easy cause you can just do it in the controller and get plenty of headroom on the ASIC itself with 
      nTime and a few midstates.
      
      > The scriptSig OTOH is variable length, so it needs to read the length byte in
      > order to figure out which 4 bytes are at the end. The pool or proxy then also
      > needs to ensure those 4 bytes are pre-initialised*.
      > 
      > 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.
      > 
      > Compared to varying the end of the scriptSig, this can be easier for an ASIC
      > because it can update a fixed 4-byte field at a known offset from the end,
      > rather than having to parse variable-length fields (notably the scriptSig
      > length) to locate the bytes to roll.
      > 
      > I think that extra complexity is doable and justifiable, but I've never built an ASIC.
      > 
      > Note that today Stratum v1 simply splits the scriptSig [5] into two parts, as does
      > Stratum v2 [3], but presumably that's all done by the control board and it makes
      > sense to want to push rolling functionally into the ASIC silicon, where even
      > simple concatenation might be too involved - but updating bytes at known
      > positions is easy.
      > 
      >> 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.
      > 
      > I don't think there's currently a speed advantage, so I wouldn't expect to observe
      > this behaviour in the wild just yet. The combination of rolling nVersion
      > (BIP310) [2] and updating nTime every second, works fine up to 280 TH/s.
      > 
      > Beyond that an ASIC will need to touch the coinbase.
      > 
      > - Sjors
      > 
      > [0] https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L47-L51
      > [1] https://bitcoin.stackexchange.com/questions/35455/why-bother-having-limitations-on-bitcoin-coinbase-transaction-scriptsigs
      > [2] https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki
      > [3] https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#511-standard-job
      > [4] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=sjors
      > [5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify
      > 
      > * = otherwise the ASIC needs to know how to extend it, know that it can't be
      > more than 100 bytes, and that it can't touch the BIP34 part, or really any
      > subsequent bytes that a future soft fork might constrain
      > 
      
      -- 
      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/33ffd6c4-6395-4f6c-a6e8-8b43220cdb00%40mattcorallo.com.
      
      
      ^ permalink raw reply	[flat|nested] 15+ messages in thread

    • • * Re: [bitcoindev] Addressing remaining points on BIP 54
          2026-01-08 16:36     ` Matt Corallo
        @ 2026-01-13  2:16       ` Antoine Riard
          2026-01-13 16:59         ` Mubarek Juhar
          0 siblings, 1 reply; 15+ messages in thread
        From: Antoine Riard @ 2026-01-13  2:16 UTC (permalink / raw)
          To: Matt Corallo
          Cc: Sjors Provoost, Bitcoin Development Mailing List, Antoine Poinsot
        
        [-- Attachment #1: Type: text/plain, Size: 6440 bytes --]
        
        Hi Corallo,
        
        > Assuming some future change to stratum v1/v2 to allow for this (which I
        think is basically a "never
        > going to happen"), its worth noting that you can't just roll it for free.
        
        This is not like there have been a multitude of pooling protocols deployed
        in the past, all with
        their awful long-polling mechanisms and other tricks. Saying we should only
        consider stratum
        v1/v2 in matters of consensus-design it can be a bit blindsighted imho. As
        of today block
        height, considering the situation where it's height-based locktime, that
        would be 19-bit
        that you could use as an extranonce, if my measurements are correct.
        
        On the other hand, making the coinbase transaction with an always valid
        coinbase's nLocktime
        transaction, this opens the door in terms of off-chain protocols and
        use-case design (e.g
        proof-of-work swap), where now you can use the consensus mandatory check of
        the coinbase
        nLocktime's field as a novel building block primitive.
        
        Best,
        Antoine
        OTS hash: 45f28303770b376e2ae8f9e0072ae236d2b42aa4c84036f87ec9903a74a385b3
        
        Le jeu. 8 janv. 2026 à 16:36, Matt Corallo <lf-lists@mattcorallo.com> a
        écrit :
        
        >
        >
        > On 1/8/26 3:30 AM, Sjors Provoost wrote:
        > > Hello Riard,
        > >
        > >> 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 coinbase scriptSig is limited to 100 bytes [0]. Some speculation as
        > to
        > > why [1].
        > >
        > > The main issue I see is complexity of implementation. The nLockTime is
        > always
        > > the last 4 bytes of a transaction, so an ASIC can roll it without having
        > to
        > > understand anything about serialisation.
        >
        > Assuming some future change to stratum v1/v2 to allow for this (which I
        > think is basically a "never
        > going to happen"), its worth noting that you can't just roll it for free.
        > Its already the case that
        > nLockTime has consensus meaning on the coinbase transaction - its enforced
        > like any other block. So
        > there's relatively little rolling you can do until you get to the current
        > block height and have to
        > go do something else (I imagine this is why its not been used for this
        > purpose in the past, at least
        > in part). So the ASIC actually has to understand quite a bit to roll this.
        >
        > Instead, in practice, ASICs (or their controllers) roll nTime, which is
        > even better cause its in the
        > header and you know you can ~always roll it once a second. Then rolling a
        > nonce in the coinbase is
        > easy cause you can just do it in the controller and get plenty of headroom
        > on the ASIC itself with
        > nTime and a few midstates.
        >
        > > The scriptSig OTOH is variable length, so it needs to read the length
        > byte in
        > > order to figure out which 4 bytes are at the end. The pool or proxy then
        > also
        > > needs to ensure those 4 bytes are pre-initialised*.
        > >
        > > 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.
        > >
        > > Compared to varying the end of the scriptSig, this can be easier for an
        > ASIC
        > > because it can update a fixed 4-byte field at a known offset from the
        > end,
        > > rather than having to parse variable-length fields (notably the scriptSig
        > > length) to locate the bytes to roll.
        > >
        > > I think that extra complexity is doable and justifiable, but I've never
        > built an ASIC.
        > >
        > > Note that today Stratum v1 simply splits the scriptSig [5] into two
        > parts, as does
        > > Stratum v2 [3], but presumably that's all done by the control board and
        > it makes
        > > sense to want to push rolling functionally into the ASIC silicon, where
        > even
        > > simple concatenation might be too involved - but updating bytes at known
        > > positions is easy.
        > >
        > >> 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.
        > >
        > > I don't think there's currently a speed advantage, so I wouldn't expect
        > to observe
        > > this behaviour in the wild just yet. The combination of rolling nVersion
        > > (BIP310) [2] and updating nTime every second, works fine up to 280 TH/s.
        > >
        > > Beyond that an ASIC will need to touch the coinbase.
        > >
        > > - Sjors
        > >
        > > [0]
        > https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L47-L51
        > > [1]
        > https://bitcoin.stackexchange.com/questions/35455/why-bother-having-limitations-on-bitcoin-coinbase-transaction-scriptsigs
        > > [2] https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki
        > > [3]
        > https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#511-standard-job
        > > [4]
        > https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=sjors
        > > [5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify
        > >
        > > * = otherwise the ASIC needs to know how to extend it, know that it
        > can't be
        > > more than 100 bytes, and that it can't touch the BIP34 part, or really
        > any
        > > subsequent bytes that a future soft fork might constrain
        > >
        >
        >
        
        -- 
        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/CALZpt%2BFf_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw%40mail.gmail.com.
        
        [-- Attachment #2: Type: text/html, Size: 8276 bytes --]
        
        ^ permalink raw reply	[flat|nested] 15+ messages in thread

      • • * Re: [bitcoindev] Addressing remaining points on BIP 54
            2026-01-13  2:16       ` Antoine Riard
          @ 2026-01-13 16:59         ` Mubarek Juhar
            0 siblings, 0 replies; 15+ messages in thread
          From: Mubarek Juhar @ 2026-01-13 16:59 UTC (permalink / raw)
            To: Antoine Riard
            Cc: Matt Corallo, Sjors Provoost, Bitcoin Development Mailing List,
          	Antoine Poinsot
          
          [-- Attachment #1: Type: text/plain, Size: 8242 bytes --]
          
          Subject
          Re: Coinbase extranonce and nLockTime
          Hi all, thanks for the clarifications. While the coinbase scriptSig is
          consensus-limited to 100 bytes, it still provides more than enough entropy
          when combined with nTime, nVersion (BIP310), and the header nonce, so
          search space exhaustion is not a practical concern today. Although
          nLockTime is attractive as a fixed-offset field, it is not free to roll due
          to its consensus semantics and limited validity window, which likely
          explains why it hasn’t seen adoption in the wild. In practice, extranonce
          handling already occurs at the controller or proxy level under Stratum
          v1/v2, meaning serialization complexity exists regardless of which coinbase
          field is varied. Given that current approaches scale to existing hash
          rates, this feels less like a performance issue and more like a
          future-proofing and design-hygiene discussion, where preserving flexibility
          in the coinbase seems prudent.
          Best,
          Mubarek
          
          On Tue, Jan 13, 2026, 5:55 AM Antoine Riard <antoine.riard@gmail.com> wrote:
          
          > Hi Corallo,
          >
          > > Assuming some future change to stratum v1/v2 to allow for this (which I
          > think is basically a "never
          > > going to happen"), its worth noting that you can't just roll it for free.
          >
          > This is not like there have been a multitude of pooling protocols deployed
          > in the past, all with
          > their awful long-polling mechanisms and other tricks. Saying we should
          > only consider stratum
          > v1/v2 in matters of consensus-design it can be a bit blindsighted imho. As
          > of today block
          > height, considering the situation where it's height-based locktime, that
          > would be 19-bit
          > that you could use as an extranonce, if my measurements are correct.
          >
          > On the other hand, making the coinbase transaction with an always valid
          > coinbase's nLocktime
          > transaction, this opens the door in terms of off-chain protocols and
          > use-case design (e.g
          > proof-of-work swap), where now you can use the consensus mandatory check
          > of the coinbase
          > nLocktime's field as a novel building block primitive.
          >
          > Best,
          > Antoine
          > OTS hash: 45f28303770b376e2ae8f9e0072ae236d2b42aa4c84036f87ec9903a74a385b3
          >
          > Le jeu. 8 janv. 2026 à 16:36, Matt Corallo <lf-lists@mattcorallo.com> a
          > écrit :
          >
          >>
          >>
          >> On 1/8/26 3:30 AM, Sjors Provoost wrote:
          >> > Hello Riard,
          >> >
          >> >> 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 coinbase scriptSig is limited to 100 bytes [0]. Some speculation as
          >> to
          >> > why [1].
          >> >
          >> > The main issue I see is complexity of implementation. The nLockTime is
          >> always
          >> > the last 4 bytes of a transaction, so an ASIC can roll it without
          >> having to
          >> > understand anything about serialisation.
          >>
          >> Assuming some future change to stratum v1/v2 to allow for this (which I
          >> think is basically a "never
          >> going to happen"), its worth noting that you can't just roll it for free.
          >> Its already the case that
          >> nLockTime has consensus meaning on the coinbase transaction - its
          >> enforced like any other block. So
          >> there's relatively little rolling you can do until you get to the current
          >> block height and have to
          >> go do something else (I imagine this is why its not been used for this
          >> purpose in the past, at least
          >> in part). So the ASIC actually has to understand quite a bit to roll this.
          >>
          >> Instead, in practice, ASICs (or their controllers) roll nTime, which is
          >> even better cause its in the
          >> header and you know you can ~always roll it once a second. Then rolling a
          >> nonce in the coinbase is
          >> easy cause you can just do it in the controller and get plenty of
          >> headroom on the ASIC itself with
          >> nTime and a few midstates.
          >>
          >> > The scriptSig OTOH is variable length, so it needs to read the length
          >> byte in
          >> > order to figure out which 4 bytes are at the end. The pool or proxy
          >> then also
          >> > needs to ensure those 4 bytes are pre-initialised*.
          >> >
          >> > 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.
          >> >
          >> > Compared to varying the end of the scriptSig, this can be easier for an
          >> ASIC
          >> > because it can update a fixed 4-byte field at a known offset from the
          >> end,
          >> > rather than having to parse variable-length fields (notably the
          >> scriptSig
          >> > length) to locate the bytes to roll.
          >> >
          >> > I think that extra complexity is doable and justifiable, but I've never
          >> built an ASIC.
          >> >
          >> > Note that today Stratum v1 simply splits the scriptSig [5] into two
          >> parts, as does
          >> > Stratum v2 [3], but presumably that's all done by the control board and
          >> it makes
          >> > sense to want to push rolling functionally into the ASIC silicon, where
          >> even
          >> > simple concatenation might be too involved - but updating bytes at known
          >> > positions is easy.
          >> >
          >> >> 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.
          >> >
          >> > I don't think there's currently a speed advantage, so I wouldn't expect
          >> to observe
          >> > this behaviour in the wild just yet. The combination of rolling nVersion
          >> > (BIP310) [2] and updating nTime every second, works fine up to 280 TH/s.
          >> >
          >> > Beyond that an ASIC will need to touch the coinbase.
          >> >
          >> > - Sjors
          >> >
          >> > [0]
          >> https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L47-L51
          >> > [1]
          >> https://bitcoin.stackexchange.com/questions/35455/why-bother-having-limitations-on-bitcoin-coinbase-transaction-scriptsigs
          >> > [2] https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki
          >> > [3]
          >> https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#511-standard-job
          >> > [4]
          >> https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=sjors
          >> > [5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify
          >> >
          >> > * = otherwise the ASIC needs to know how to extend it, know that it
          >> can't be
          >> > more than 100 bytes, and that it can't touch the BIP34 part, or really
          >> any
          >> > subsequent bytes that a future soft fork might constrain
          >> >
          >>
          >> --
          > 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/CALZpt%2BFf_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw%40mail.gmail.com
          > <https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BFf_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw%40mail.gmail.com?utm_medium=email&utm_source=footer>
          > .
          >
          
          -- 
          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/CAOCjFt9QktYQ%2B9Z-peYJHaXSgJuHwCZGZHiWyMbm2LwK5ztUKg%40mail.gmail.com.
          
          [-- Attachment #2: Type: text/html, Size: 10507 bytes --]
          
          ^ permalink raw reply	[flat|nested] 15+ messages in thread

    • * Re: [bitcoindev] Addressing remaining points on BIP 54
        2026-01-08  8:30   ` [bitcoindev] " Sjors Provoost
        2026-01-08 16:36     ` Matt Corallo
      @ 2026-01-08 16:40     ` Matt Corallo
        2026-01-13  1:49     ` Antoine Riard
        2026-01-14  0:23     ` Murch
        3 siblings, 0 replies; 15+ messages in thread
      From: Matt Corallo @ 2026-01-08 16:40 UTC (permalink / raw)
        To: Sjors Provoost, Antoine Riard
        Cc: Bitcoin Development Mailing List, Antoine Poinsot
      
      
      
      On 1/8/26 3:30 AM, Sjors Provoost wrote:
      > Hello Riard,
      > 
      >> 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 coinbase scriptSig is limited to 100 bytes [0]. Some speculation as to
      > why [1].
      > 
      > The main issue I see is complexity of implementation. The nLockTime is always
      > the last 4 bytes of a transaction, so an ASIC can roll it without having to
      > understand anything about serialisation.
      > 
      > The scriptSig OTOH is variable length, so it needs to read the length byte in
      > order to figure out which 4 bytes are at the end. The pool or proxy then also
      > needs to ensure those 4 bytes are pre-initialised*.
      > 
      > 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.
      > 
      > Compared to varying the end of the scriptSig, this can be easier for an ASIC
      > because it can update a fixed 4-byte field at a known offset from the end,
      > rather than having to parse variable-length fields (notably the scriptSig
      > length) to locate the bytes to roll.
      > 
      > I think that extra complexity is doable and justifiable, but I've never built an ASIC.
      > 
      > Note that today Stratum v1 simply splits the scriptSig [5] into two parts, as does
      > Stratum v2 [3], but presumably that's all done by the control board and it makes
      > sense to want to push rolling functionally into the ASIC silicon, where even
      > simple concatenation might be too involved - but updating bytes at known
      > positions is easy.
      > 
      >> 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.
      > 
      > I don't think there's currently a speed advantage, so I wouldn't expect to observe
      > this behaviour in the wild just yet. The combination of rolling nVersion
      > (BIP310) [2] and updating nTime every second, works fine up to 280 TH/s.
      > 
      > Beyond that an ASIC will need to touch the coinbase.
      
      Oops, missed this part. Honestly we should just reserve another 8 bits out of the version for 
      rolling. 8 bits for signaling is more than enough, and 72PH/2 aught to be enough for a relatively 
      large ASIC for quite a while :). Then this entire rolling discussion nearly entirely goes away.
      
      -- 
      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/f68d7c20-5119-4159-8e42-f7c10597a789%40mattcorallo.com.
      
      
      ^ permalink raw reply	[flat|nested] 15+ messages in thread

    • * Re: [bitcoindev] Addressing remaining points on BIP 54
        2026-01-08  8:30   ` [bitcoindev] " Sjors Provoost
        2026-01-08 16:36     ` Matt Corallo
        2026-01-08 16:40     ` Matt Corallo
      @ 2026-01-13  1:49     ` Antoine Riard
        2026-01-14  0:23     ` Murch
        3 siblings, 0 replies; 15+ messages in thread
      From: Antoine Riard @ 2026-01-13  1:49 UTC (permalink / raw)
        To: Sjors Provoost; +Cc: Bitcoin Development Mailing List, Antoine Poinsot
      
      [-- Attachment #1: Type: text/plain, Size: 6653 bytes --]
      
      Hi Sjors,
      
      Thanks for the reminder that the coinbase transaction has a 100 bytes
      limit, checked IsCoinbase(), but I didn't CheckTransaction() again. So with
      a 100 bytes limit, there are still 2^100 extra permutations in addition to
      the
      128 bits already available from the nonce, and the bits from the version
      fields.
      
      It is true that the coinbase nLocktime is a fixed-size field, so an ASIC can
      roll it without having it ot understand anything about serialization, while
      on
      the other hand the scriptSig is as you're noting variable-length (well you
      can
      make assumptions on the var_int fixed-size). I don't think that that
      whatever
      your ASIC design, the chip has to be aware of the serialization subtleties,
      this can be done at the proxy-level, and you just feed an unified iterable
      bits field (version + scriptSig + coinbase, whatever you use as an
      extranonce).
      
      I see the idea of appending a 0-sat OP_RETURN output with padding so a
      4-byte
      nonce is fitting in the data payload of the OP_RETURN. But I don't see how
      you avoid the unserialization problem for the proxy of knowing the OP_RETURN
      data payload selected size (--I guess register loads and CPU cycles saved
      at the architecture levels for the unser buffer mem allocation can be wins
      for the proxy). So it might be easier to implement, but not necessarily
      faster.
      
      Never built an ASIC, but to have studied instruction level architecture, if
      you
      wish optimal performance the question starts to be the size of you're
      high-level
      cache (the ones the nearest of your roll-and-hash-logic) and what is the
      byte-length
      words those caches are working on. Unless you're iterating on 4 MB words
      fractional
      power of 2 of it, but I don't think so.
      
      I'm not aware this behaviour is done in the wild, but in theory if you can
      serialize / unserialize on fixed-size data fields for the proxy, it's faster
      (just one less one memory allocator call...).
      
      Without digging more on the necessities for current 280 TH/s, this can be
      fine for
      now to just roll the nVersion header field which is a fixed-size too,
      though I do think
      Luke's concern of letting the coinbase as a reserved field for now is not
      without ground
      (of course the nLocktime can be valid today, but what is the worthiness as
      the nSequence
      can be set to disable it, i.e IsFinal()'s semantic).
      
      Best,
      Antoine
      OTS hash: 6c1f83a60642ef43c911dd57b4b9aaf084cf80445d0af72b1f92f910581f6ead
      
      Le jeu. 8 janv. 2026 à 08:30, Sjors Provoost <sjors@sprovoost.nl> a écrit :
      
      > Hello Riard,
      >
      > > 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 coinbase scriptSig is limited to 100 bytes [0]. Some speculation as to
      > why [1].
      >
      > The main issue I see is complexity of implementation. The nLockTime is
      > always
      > the last 4 bytes of a transaction, so an ASIC can roll it without having to
      > understand anything about serialisation.
      >
      > The scriptSig OTOH is variable length, so it needs to read the length byte
      > in
      > order to figure out which 4 bytes are at the end. The pool or proxy then
      > also
      > needs to ensure those 4 bytes are pre-initialised*.
      >
      > 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.
      >
      > Compared to varying the end of the scriptSig, this can be easier for an
      > ASIC
      > because it can update a fixed 4-byte field at a known offset from the end,
      > rather than having to parse variable-length fields (notably the scriptSig
      > length) to locate the bytes to roll.
      >
      > I think that extra complexity is doable and justifiable, but I've never
      > built an ASIC.
      >
      > Note that today Stratum v1 simply splits the scriptSig [5] into two parts,
      > as does
      > Stratum v2 [3], but presumably that's all done by the control board and it
      > makes
      > sense to want to push rolling functionally into the ASIC silicon, where
      > even
      > simple concatenation might be too involved - but updating bytes at known
      > positions is easy.
      >
      > > 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.
      >
      > I don't think there's currently a speed advantage, so I wouldn't expect to
      > observe
      > this behaviour in the wild just yet. The combination of rolling nVersion
      > (BIP310) [2] and updating nTime every second, works fine up to 280 TH/s.
      >
      > Beyond that an ASIC will need to touch the coinbase.
      >
      > - Sjors
      >
      > [0]
      > https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L47-L51
      > [1]
      > https://bitcoin.stackexchange.com/questions/35455/why-bother-having-limitations-on-bitcoin-coinbase-transaction-scriptsigs
      > [2] https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki
      > [3]
      > https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#511-standard-job
      > [4]
      > https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=sjors
      > [5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify
      >
      > * = otherwise the ASIC needs to know how to extend it, know that it can't
      > be
      > more than 100 bytes, and that it can't touch the BIP34 part, or really any
      > subsequent bytes that a future soft fork might constrain
      
      -- 
      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/CALZpt%2BFyPWsbvNOo3jpSoBR08a-LXoZi40yaP5VFEaKm%3DNYRPw%40mail.gmail.com.
      
      [-- Attachment #2: Type: text/html, Size: 8301 bytes --]
      
      ^ permalink raw reply	[flat|nested] 15+ messages in thread

    • * Re: [bitcoindev] Addressing remaining points on BIP 54
        2026-01-08  8:30   ` [bitcoindev] " Sjors Provoost
                             ` (2 preceding siblings ...)
        2026-01-13  1:49     ` Antoine Riard
      @ 2026-01-14  0:23     ` Murch
        2026-01-14 10:15       ` Sjors Provoost
        3 siblings, 1 reply; 15+ messages in thread
      From: Murch @ 2026-01-14  0:23 UTC (permalink / raw)
        To: bitcoindev; +Cc: Sjors Provoost
      
      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+unsubscribe@googlegroups.com.
      To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/492f9bba-8a1f-4fa2-8618-98bd564a6178%40murch.one.
      
      
      ^ permalink raw reply	[flat|nested] 15+ messages in thread

    • • * Re: [bitcoindev] Addressing remaining points on BIP 54
          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
          0 siblings, 1 reply; 15+ messages in thread
        From: Sjors Provoost @ 2026-01-14 10:15 UTC (permalink / raw)
          To: bitcoindev; +Cc: Murch
        
        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 <murch@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+unsubscribe@googlegroups.com.
        To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1B807731-DC2A-4E59-B462-5C210EF1FB73%40sprovoost.nl.
        
        
        ^ permalink raw reply	[flat|nested] 15+ messages in thread

      • • * Re: [bitcoindev] Addressing remaining points on BIP 54
            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
            0 siblings, 1 reply; 15+ messages in thread
          From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2026-01-14 15:33 UTC (permalink / raw)
            To: Murch, Sjors Provoost; +Cc: bitcoindev
          
          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 <sjors@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 murch@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+unsubscribe@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/_C0iWeaJ-v24dZgcdCnKZKEgK9E493DmpG_-wD1NZnOAuECi97dZpVLuZxkONIfZjTe7km_TWFdSFfmSzVWfJ5Lkz6JTc8JwDOTg9XAInVo%3D%40protonmail.com.
          
          
          ^ permalink raw reply	[flat|nested] 15+ messages in thread

        • • * Re: [bitcoindev] Addressing remaining points on BIP 54
              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
              0 siblings, 1 reply; 15+ messages in thread
            From: Murch @ 2026-01-14 18:58 UTC (permalink / raw)
              To: Antoine Poinsot, Sjors Provoost; +Cc: bitcoindev
            
            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 <sjors@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 murch@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+unsubscribe@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/1dd74f45-bd0a-4fd7-bf80-56a3b2a44128%40murch.one.
            
            
            ^ permalink raw reply	[flat|nested] 15+ messages in thread

          • • * Re: [bitcoindev] Addressing remaining points on BIP 54
                2026-01-14 18:58           ` Murch
              @ 2026-01-30  4:08             ` Antoine Riard
                2026-02-05 22:48               ` 'Antoine Poinsot' via Bitcoin Development Mailing List
                0 siblings, 1 reply; 15+ messages in thread
              From: Antoine Riard @ 2026-01-30  4:08 UTC (permalink / raw)
                To: Bitcoin Development Mailing List
              
              
              [-- 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 --]
              
              ^ permalink raw reply	[flat|nested] 15+ messages in thread

            • • * Re: [bitcoindev] Addressing remaining points on BIP 54
                  2026-01-30  4:08             ` Antoine Riard
                @ 2026-02-05 22:48               ` 'Antoine Poinsot' via Bitcoin Development Mailing List
                  2026-02-12  3:57                 ` Antoine Riard
                  0 siblings, 1 reply; 15+ messages in thread
                From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2026-02-05 22:48 UTC (permalink / raw)
                  To: Antoine Riard; +Cc: Bitcoin Development Mailing List
                
                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 <antoine.riard@gmail.com> 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 <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.
                
                -- 
                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/0Gc3rCZzaVbzL88b9G3EDjXdayArs8JtirCO2nmmMVLDgbxovIEu7-hhQp0G4wPnEB3YABywEppEFbC-zSudJUiR7HW680kM6LWtHDmp_Hc%3D%40protonmail.com.
                
                
                ^ permalink raw reply	[flat|nested] 15+ messages in thread

              • • * Re: [bitcoindev] Addressing remaining points on BIP 54
                    2026-02-05 22:48               ` 'Antoine Poinsot' via Bitcoin Development Mailing List
                  @ 2026-02-12  3:57                 ` Antoine Riard
                    0 siblings, 0 replies; 15+ messages in thread
                  From: Antoine Riard @ 2026-02-12  3:57 UTC (permalink / raw)
                    To: Bitcoin Development Mailing List
                  
                  
                  [-- Attachment #1.1: Type: text/plain, Size: 18942 bytes --]
                  
                  Hi,
                  
                  Thanks for your insightful additional comments on the BIP rational.
                  
                  > 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.
                  
                  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 == 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 ==
                  nHeight - 1, it is implying logicall that nLocktime < nBlockHeight
                  if nHeight == 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 
                  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.
                  
                  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: “BIP30 validation is 
                  never
                  necessary after CC activation height”.
                  
                  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 
                  hypothetical
                  situation of hard-fork as you're pointing apparently the 227,835 first 
                  blocks 
                  have been set with a nLocktime of 0), a pre-BIP54 coinbase transaction could
                  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 
                  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 
                  coinbase
                  transaction nLocktime must be exactly set to the height of the checked 
                  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 
                  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-bits.
                  
                  Best,
                  Antoine
                  OTS hash: 85b441de80dc914f5b5ef15f2ea8b6f6493755b4b58840e9bf3908781ebdbca8
                  
                  [0] 
                  https://github.com/bitcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531  
                  
                  Le Thursday, February 5, 2026 à 10:52:13 PM UTC, Antoine Poinsot a écrit :
                  
                  > 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 <
                  > antoin...@gmail.com> 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 <
                  > 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+...@googlegroups.com.
                  > > 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 bitcoindev+unsubscribe@googlegroups.com.
                  To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1922c72f-3288-42b4-b5ad-9757440348c5n%40googlegroups.com.
                  
                  [-- Attachment #1.2: Type: text/html, Size: 23927 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2026-02-12  9:03 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-30 15:59 [bitcoindev] Addressing remaining points on BIP 54 '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
2026-02-05 22:48               ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-02-12  3:57                 ` Antoine Riard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox