public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoindev] Consensus Cleanup BIP draft
@ 2025-03-26 17:14 'Antoine Poinsot' via Bitcoin Development Mailing List
  2025-03-27 10:46 ` Chris Stewart
  0 siblings, 1 reply; 16+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-26 17:14 UTC (permalink / raw)
  To: Bitcoin Development Mailing List

Hi everyone,

About two months ago i shared an update on this list about my (and others', really) work on the
Consensus Cleanup [0]. I am now ready to share a BIP draft for a Consensus Cleanup soft fork.

The BIP draft can be found here: https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md

It includes the following fixes:
- a restriction on the timestamp of the first and last blocks of a difficulty adjustment period to
  address the Timewarp and Murch-Zawy attacks;
- a limit on the number of legacy signature operations that may be executed in validating a single
  transaction to address long block validation times;
- making 64 bytes transactions invalid to address weaknesses in the block Merkle tree construction;
- mandating coinbase transactions be timelocked to their block height to prevent future transaction
  duplication without resorting to BIP30 validation.

This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt Corallo [1]. A number of
people contributed ideas, testing, data or useful discussions. This includes Ava Chow, Matt Corallo,
Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony Towns, Greg Sanders, Chris
Stewart, Eric Voskuil, @0xb10c and others.

Antoine Poinsot

[0] https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com
[1] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki

-- 
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/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.com.


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

• * Re: [bitcoindev] Consensus Cleanup BIP draft
    2025-03-26 17:14 [bitcoindev] Consensus Cleanup BIP draft 'Antoine Poinsot' via Bitcoin Development Mailing List
  @ 2025-03-27 10:46 ` Chris Stewart
    2025-03-27 17:54   ` /dev /fd0
    2025-03-27 19:05   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
    0 siblings, 2 replies; 16+ messages in thread
  From: Chris Stewart @ 2025-03-27 10:46 UTC (permalink / raw)
    To: Antoine Poinsot; +Cc: Bitcoin Development Mailing List
  
  [-- Attachment #1: Type: text/plain, Size: 4545 bytes --]
  
  Hi Antoine,
  
  First off, concept ACK. My concerns are procedural rather than objections
  to the individual security fixes themselves.
  
  The "Great Consensus Cleanup" is a fantastic brand for communicating these
  protocol changes to non-technical users. However, since this is a technical
  forum and we are producing BIPs intended for technical audiences, I believe
  we should document these changes in separate BIPs.
  
  The proposed security fixes are largely unrelated from a technical
  standpoint:
  
     1.
  
     Timewarp attack mitigation
     2.
  
     Worst-case block validation constraints
     3.
  
     Disallowing 64-byte transactions
     4.
  
     Avoiding duplicate transactions
  
  We should absolutely retain the "Great Consensus Cleanup" branding while
  independently documenting each security enhancement.
  
  A common concern I’ve heard about splitting this BIP is that deploying soft
  forks is difficult, so all changes should be bundled together. While soft
  fork deployment is indeed challenging, we've successfully activated
  multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143
  in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the
  community reaches consensus, we can still deploy all these changes
  together, even if they are documented separately.
  
  This approach also provides flexibility: if one of the proposed changes
  turns out to be controversial, we could remove it without holding up the
  rest of the improvements. Additionally, once these fixes are deployed,
  there will likely be significant research and documentation to incorporate,
  and maintaining independent BIPs will make it easier to manage that growth.
  
  I do see merit in implementing all the security fixes in a single PR for
  Bitcoin Core. More active contributors to the project may have stronger
  opinions on the best approach there.
  
  -Chris
  ------------------------------
  
  
  
  
  On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via Bitcoin Development
  Mailing List <bitcoindev@googlegroups.com> wrote:
  
  > Hi everyone,
  >
  > About two months ago i shared an update on this list about my (and
  > others', really) work on the
  > Consensus Cleanup [0]. I am now ready to share a BIP draft for a Consensus
  > Cleanup soft fork.
  >
  > The BIP draft can be found here:
  > https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
  >
  > It includes the following fixes:
  > - a restriction on the timestamp of the first and last blocks of a
  > difficulty adjustment period to
  >   address the Timewarp and Murch-Zawy attacks;
  > - a limit on the number of legacy signature operations that may be
  > executed in validating a single
  >   transaction to address long block validation times;
  > - making 64 bytes transactions invalid to address weaknesses in the block
  > Merkle tree construction;
  > - mandating coinbase transactions be timelocked to their block height to
  > prevent future transaction
  >   duplication without resorting to BIP30 validation.
  >
  > This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt
  > Corallo [1]. A number of
  > people contributed ideas, testing, data or useful discussions. This
  > includes Ava Chow, Matt Corallo,
  > Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony
  > Towns, Greg Sanders, Chris
  > Stewart, Eric Voskuil, @0xb10c and others.
  >
  > Antoine Poinsot
  >
  > [0]
  > https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com
  > [1]
  > https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
  >
  > --
  > 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/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.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/CAGL6%2BmFQqTS21cQZ_aU%3DhXtMaKkw5ygAk2PT9hQpdB4THz9X_A%40mail.gmail.com.
  
  [-- Attachment #2: Type: text/html, Size: 6218 bytes --]
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [bitcoindev] Consensus Cleanup BIP draft
      2025-03-27 10:46 ` Chris Stewart
    @ 2025-03-27 17:54   ` /dev /fd0
      2025-03-27 19:05   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
      1 sibling, 0 replies; 16+ messages in thread
    From: /dev /fd0 @ 2025-03-27 17:54 UTC (permalink / raw)
      To: Bitcoin Development Mailing List
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 5015 bytes --]
    
    Hi Chris,
    
    I agree with separation.
    
    Also I need more details as some of them could be CIA proxy and introduce 
    another bug. Any change in consensus code need more discussion.
    
    /dev/fd0
    floppy disk guy 
    
    On Thursday, March 27, 2025 at 5:49:30 PM UTC+5:30 Chris Stewart wrote:
    
    > Hi Antoine, 
    >
    > First off, concept ACK. My concerns are procedural rather than objections 
    > to the individual security fixes themselves.
    >
    > The "Great Consensus Cleanup" is a fantastic brand for communicating these 
    > protocol changes to non-technical users. However, since this is a technical 
    > forum and we are producing BIPs intended for technical audiences, I believe 
    > we should document these changes in separate BIPs.
    >
    > The proposed security fixes are largely unrelated from a technical 
    > standpoint:
    >
    >    1. 
    >    
    >    Timewarp attack mitigation
    >    2. 
    >    
    >    Worst-case block validation constraints
    >    3. 
    >    
    >    Disallowing 64-byte transactions
    >    4. 
    >    
    >    Avoiding duplicate transactions
    >    
    > We should absolutely retain the "Great Consensus Cleanup" branding while 
    > independently documenting each security enhancement.
    >
    > A common concern I’ve heard about splitting this BIP is that deploying 
    > soft forks is difficult, so all changes should be bundled together. While 
    > soft fork deployment is indeed challenging, we've successfully activated 
    > multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 
    > in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the 
    > community reaches consensus, we can still deploy all these changes 
    > together, even if they are documented separately.
    >
    > This approach also provides flexibility: if one of the proposed changes 
    > turns out to be controversial, we could remove it without holding up the 
    > rest of the improvements. Additionally, once these fixes are deployed, 
    > there will likely be significant research and documentation to incorporate, 
    > and maintaining independent BIPs will make it easier to manage that growth.
    >
    > I do see merit in implementing all the security fixes in a single PR for 
    > Bitcoin Core. More active contributors to the project may have stronger 
    > opinions on the best approach there.
    >
    > -Chris 
    > ------------------------------
    >
    >
    >
    >
    > On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via Bitcoin Development 
    > Mailing List <bitco...@googlegroups•com> wrote:
    >
    >> Hi everyone,
    >>
    >> About two months ago i shared an update on this list about my (and 
    >> others', really) work on the
    >> Consensus Cleanup [0]. I am now ready to share a BIP draft for a 
    >> Consensus Cleanup soft fork.
    >>
    >> The BIP draft can be found here: 
    >> https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
    >>
    >> It includes the following fixes:
    >> - a restriction on the timestamp of the first and last blocks of a 
    >> difficulty adjustment period to
    >>   address the Timewarp and Murch-Zawy attacks;
    >> - a limit on the number of legacy signature operations that may be 
    >> executed in validating a single
    >>   transaction to address long block validation times;
    >> - making 64 bytes transactions invalid to address weaknesses in the block 
    >> Merkle tree construction;
    >> - mandating coinbase transactions be timelocked to their block height to 
    >> prevent future transaction
    >>   duplication without resorting to BIP30 validation.
    >>
    >> This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt 
    >> Corallo [1]. A number of
    >> people contributed ideas, testing, data or useful discussions. This 
    >> includes Ava Chow, Matt Corallo,
    >> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony 
    >> Towns, Greg Sanders, Chris
    >> Stewart, Eric Voskuil, @0xb10c and others.
    >>
    >> Antoine Poinsot
    >>
    >> [0] 
    >> https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com
    >> [1] 
    >> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
    >>
    >> -- 
    >> 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/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.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/e32b5d5c-1326-451c-b2eb-d7a92c50d9ban%40googlegroups.com.
    
    [-- Attachment #1.2: Type: text/html, Size: 8253 bytes --]
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • * Re: [bitcoindev] Consensus Cleanup BIP draft
      2025-03-27 10:46 ` Chris Stewart
      2025-03-27 17:54   ` /dev /fd0
    @ 2025-03-27 19:05   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
      2025-03-27 20:45     ` jeremy
      1 sibling, 1 reply; 16+ messages in thread
    From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-27 19:05 UTC (permalink / raw)
      To: Chris Stewart; +Cc: Bitcoin Development Mailing List
    
    [-- Attachment #1: Type: text/plain, Size: 6445 bytes --]
    
    Hi Chris,
    
    As i already explained on this very list 2 months ago [0], i don't find the argument for splitting my BIP convincing. On the contrary i think it would be counterproductive as it would create more churn, invite bikeshedding and overall impede progress on this proposal.
    
    > we've successfully activated multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot.
    
    Those BIPs had much more content to them. The specifications of the Consensus Cleanup is trivial in comparison: they fit in less than a dozen lines of text when described in details. Splitting them in 4 different BIPs with a single or a couple lines of specifications would just introduce unnecessary overhead.
    
    > if one of the proposed changes turns out to be controversial, we could remove it without holding up the rest of the improvements.
    
    First of all, i do not expect to remove any of the mitigations from the BIP at this stage. The fact that each of these mitigations was researched and discussed at length by multiple people over the past year gives me confidence to move forward with every single one of those. Otherwise i would not have proposed this BIP in the first place.
    
    Now, even if somehow we should drop one of the mitigations from the proposal, having them in separate BIPs does not make that any easier.
    
    > More active contributors to the project may have stronger opinions on the best approach there.
    
    Yes.
    
    Best,
    Antoine
    
    [0] https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=@protonmail.com
    On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart <stewart.chris1234@gmail•com> wrote:
    
    > Hi Antoine,
    >
    > First off, concept ACK. My concerns are procedural rather than objections to the individual security fixes themselves.
    >
    > The "Great Consensus Cleanup" is a fantastic brand for communicating these protocol changes to non-technical users. However, since this is a technical forum and we are producing BIPs intended for technical audiences, I believe we should document these changes in separate BIPs.
    >
    > The proposed security fixes are largely unrelated from a technical standpoint:
    >
    > -
    >
    > Timewarp attack mitigation
    >
    > -
    >
    > Worst-case block validation constraints
    >
    > -
    >
    > Disallowing 64-byte transactions
    >
    > -
    >
    > Avoiding duplicate transactions
    >
    > We should absolutely retain the "Great Consensus Cleanup" branding while independently documenting each security enhancement.
    >
    > A common concern I’ve heard about splitting this BIP is that deploying soft forks is difficult, so all changes should be bundled together. While soft fork deployment is indeed challenging, we've successfully activated multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the community reaches consensus, we can still deploy all these changes together, even if they are documented separately.
    >
    > This approach also provides flexibility: if one of the proposed changes turns out to be controversial, we could remove it without holding up the rest of the improvements. Additionally, once these fixes are deployed, there will likely be significant research and documentation to incorporate, and maintaining independent BIPs will make it easier to manage that growth.
    >
    > I do see merit in implementing all the security fixes in a single PR for Bitcoin Core. More active contributors to the project may have stronger opinions on the best approach there.
    >
    > -Chris
    >
    > ---------------------------------------------------------------
    >
    > On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
    >
    >> Hi everyone,
    >>
    >> About two months ago i shared an update on this list about my (and others', really) work on the
    >> Consensus Cleanup [0]. I am now ready to share a BIP draft for a Consensus Cleanup soft fork.
    >>
    >> The BIP draft can be found here: https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
    >>
    >> It includes the following fixes:
    >> - a restriction on the timestamp of the first and last blocks of a difficulty adjustment period to
    >> address the Timewarp and Murch-Zawy attacks;
    >> - a limit on the number of legacy signature operations that may be executed in validating a single
    >> transaction to address long block validation times;
    >> - making 64 bytes transactions invalid to address weaknesses in the block Merkle tree construction;
    >> - mandating coinbase transactions be timelocked to their block height to prevent future transaction
    >> duplication without resorting to BIP30 validation.
    >>
    >> This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt Corallo [1]. A number of
    >> people contributed ideas, testing, data or useful discussions. This includes Ava Chow, Matt Corallo,
    >> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony Towns, Greg Sanders, Chris
    >> Stewart, Eric Voskuil, @0xb10c and others.
    >>
    >> Antoine Poinsot
    >>
    >> [0] https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com
    >> [1] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
    >>
    >> --
    >> 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](mailto:bitcoindev%2Bunsubscribe@googlegroups•com).
    >> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.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/TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV_C9rJEkKTvudWSG8CJsq16jPhQBjM0eVmPe8rir50Y4%3D%40protonmail.com.
    
    [-- Attachment #2: Type: text/html, Size: 10448 bytes --]
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • • * Re: [bitcoindev] Consensus Cleanup BIP draft
        2025-03-27 19:05   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
      @ 2025-03-27 20:45     ` jeremy
        2025-03-27 21:38       ` 'Antoine Poinsot' via Bitcoin Development Mailing List
                               ` (2 more replies)
        0 siblings, 3 replies; 16+ messages in thread
      From: jeremy @ 2025-03-27 20:45 UTC (permalink / raw)
        To: Bitcoin Development Mailing List
      
      
      [-- Attachment #1.1: Type: text/plain, Size: 8039 bytes --]
      
      > First of all, i do not expect to remove any of the mitigations from the 
      BIP at this stage. The fact that each of these mitigations was researched 
      and discussed at length by multiple people over the past year gives me 
      confidence to move forward with every single one of those. Otherwise i 
      would not have proposed this BIP in the first place.
      
      I'd recommend taking a much more flexible mindset at this stage. The set of 
      eyeballs you get at a pre-BIP and BIP stage, and the level of attention are 
      very different, and this type of messaging is very discouraging for someone 
      with expertise to care to put review in v.s. disregarding the effort as 
      non-constructive.
      
      Critically:
      
      In your "discussed at length" proposal, you failed to realize that there 
      were indeed 64 byte transactions on-chain until it was pointed out to you 7 
      days ago.
      
      You also include a hack using coinbase nSequence -- have you bothered to 
      talk to anyone in the mining business how they feel about that? Are you 
      sure no ASIC in the wild don't hardcode a field that never needed to be set 
      before?
      
      I'm also personally strongly against removing 64-byte transactions. It's a 
      wart in how transactions work, and future upgrades (especially around tx 
      programmability) might integrate very poorly with this kind of edge 
      condition.
      
      regards,
      
      Jeremy
      
      On Thursday, March 27, 2025 at 3:36:13 PM UTC-4 Antoine Poinsot wrote:
      
      > Hi Chris,
      >
      > As i already explained on this very list 2 months ago [0], i don't find 
      > the argument for splitting my BIP convincing. On the contrary i think it 
      > would be counterproductive as it would create more churn, invite 
      > bikeshedding and overall impede progress on this proposal.
      >
      > we've successfully activated multiple BIPs within a single soft fork in 
      > the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and 
      > BIP343 in Taproot.
      >
      >
      > Those BIPs had much more content to them. The specifications of the 
      > Consensus Cleanup is trivial in comparison: they fit in less than a dozen 
      > lines of text when described in details. Splitting them in 4 different BIPs 
      > with a single or a couple lines of specifications would just introduce 
      > unnecessary overhead.
      >
      > if one of the proposed changes turns out to be controversial, we could 
      > remove it without holding up the rest of the improvements.
      >
      >
      > First of all, i do not expect to remove any of the mitigations from the 
      > BIP at this stage. The fact that each of these mitigations was researched 
      > and discussed at length by multiple people over the past year gives me 
      > confidence to move forward with every single one of those. Otherwise i 
      > would not have proposed this BIP in the first place.
      >
      > Now, even if somehow we should drop one of the mitigations from the 
      > proposal, having them in separate BIPs does not make that any easier.
      >
      > More active contributors to the project may have stronger opinions on the 
      > best approach there.
      >
      >
      > Yes.
      >
      > Best,
      > Antoine
      >
      > [0] 
      > https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=@protonmail.com
      > On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart <
      > stewart....@gmail•com> wrote:
      >
      > Hi Antoine, 
      >
      > First off, concept ACK. My concerns are procedural rather than objections 
      > to the individual security fixes themselves.
      >
      > The "Great Consensus Cleanup" is a fantastic brand for communicating these 
      > protocol changes to non-technical users. However, since this is a technical 
      > forum and we are producing BIPs intended for technical audiences, I believe 
      > we should document these changes in separate BIPs.
      >
      > The proposed security fixes are largely unrelated from a technical 
      > standpoint:
      >
      >    1. 
      >    
      >    Timewarp attack mitigation
      >    2. 
      >    
      >    Worst-case block validation constraints
      >    3. 
      >    
      >    Disallowing 64-byte transactions
      >    4. 
      >    
      >    Avoiding duplicate transactions
      >    
      > We should absolutely retain the "Great Consensus Cleanup" branding while 
      > independently documenting each security enhancement.
      >
      > A common concern I’ve heard about splitting this BIP is that deploying 
      > soft forks is difficult, so all changes should be bundled together. While 
      > soft fork deployment is indeed challenging, we've successfully activated 
      > multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 
      > in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the 
      > community reaches consensus, we can still deploy all these changes 
      > together, even if they are documented separately.
      >
      > This approach also provides flexibility: if one of the proposed changes 
      > turns out to be controversial, we could remove it without holding up the 
      > rest of the improvements. Additionally, once these fixes are deployed, 
      > there will likely be significant research and documentation to incorporate, 
      > and maintaining independent BIPs will make it easier to manage that growth.
      >
      > I do see merit in implementing all the security fixes in a single PR for 
      > Bitcoin Core. More active contributors to the project may have stronger 
      > opinions on the best approach there.
      >
      > -Chris 
      > ------------------------------
      >
      >
      >
      >
      > On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via Bitcoin Development 
      > Mailing List <bitco...@googlegroups•com> wrote:
      >
      >> Hi everyone,
      >>
      >> About two months ago i shared an update on this list about my (and 
      >> others', really) work on the
      >> Consensus Cleanup [0]. I am now ready to share a BIP draft for a 
      >> Consensus Cleanup soft fork.
      >>
      >> The BIP draft can be found here: 
      >> https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
      >>
      >> It includes the following fixes:
      >> - a restriction on the timestamp of the first and last blocks of a 
      >> difficulty adjustment period to
      >> address the Timewarp and Murch-Zawy attacks;
      >> - a limit on the number of legacy signature operations that may be 
      >> executed in validating a single
      >> transaction to address long block validation times;
      >> - making 64 bytes transactions invalid to address weaknesses in the block 
      >> Merkle tree construction;
      >> - mandating coinbase transactions be timelocked to their block height to 
      >> prevent future transaction
      >> duplication without resorting to BIP30 validation.
      >>
      >> This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt 
      >> Corallo [1]. A number of
      >> people contributed ideas, testing, data or useful discussions. This 
      >> includes Ava Chow, Matt Corallo,
      >> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony 
      >> Towns, Greg Sanders, Chris
      >> Stewart, Eric Voskuil, @0xb10c and others.
      >>
      >> Antoine Poinsot
      >>
      >> [0] 
      >> https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com
      >> [1] 
      >> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
      >>
      >> -- 
      >> 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/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.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/afedbc69-8042-4fe8-99c2-279173a440f3n%40googlegroups.com.
      
      [-- Attachment #1.2: Type: text/html, Size: 13928 bytes --]
      
      ^ permalink raw reply	[flat|nested] 16+ messages in thread

    • • * Re: [bitcoindev] Consensus Cleanup BIP draft
          2025-03-27 20:45     ` jeremy
        @ 2025-03-27 21:38       ` 'Antoine Poinsot' via Bitcoin Development Mailing List
          2025-03-28  9:23       ` Sjors Provoost
          2025-03-28 19:53       ` eric
          2 siblings, 0 replies; 16+ messages in thread
        From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-27 21:38 UTC (permalink / raw)
          To: bitcoindev
        
        [-- Attachment #1: Type: text/plain, Size: 9547 bytes --]
        
        Jeremy,
        
        Thanks for your recommendations. I suggest you lead by example.
        
        "Discussed at length" is not about me. My hastily sharing mistaken results [0] a week ago shouldn't obscure the fact that 64 bytes transactions have been studied and generally considered harmful since at least 2017 [1], almost a decade ago.
        
        Regarding your other questions i don't think you, of all people, are in a position of taking this moral high ground and interrogating tone when it comes to consulting industry stakeholders at large about a consensus change.
        
        That said, i (as well as others) have in fact been discussing Consensus Cleanup with some miners (hashers as well as pools) for a while. I intend to share some testing results soon.
        
        Antoine
        
        [0] [https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/82](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/82?u=antoinep)
        [1] [https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design](https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/)
        On Thursday, March 27th, 2025 at 4:45 PM, jeremy <jeremy.l.rubin@gmail•com> wrote:
        
        >> First of all, i do not expect to remove any of the mitigations from the BIP at this stage. The fact that each of these mitigations was researched and discussed at length by multiple people over the past year gives me confidence to move forward with every single one of those. Otherwise i would not have proposed this BIP in the first place.
        >
        > I'd recommend taking a much more flexible mindset at this stage. The set of eyeballs you get at a pre-BIP and BIP stage, and the level of attention are very different, and this type of messaging is very discouraging for someone with expertise to care to put review in v.s. disregarding the effort as non-constructive.
        >
        > Critically:
        >
        > In your "discussed at length" proposal, you failed to realize that there were indeed 64 byte transactions on-chain until it was pointed out to you 7 days ago.
        >
        > You also include a hack using coinbase nSequence -- have you bothered to talk to anyone in the mining business how they feel about that? Are you sure no ASIC in the wild don't hardcode a field that never needed to be set before?
        >
        > I'm also personally strongly against removing 64-byte transactions. It's a wart in how transactions work, and future upgrades (especially around tx programmability) might integrate very poorly with this kind of edge condition.
        >
        > regards,
        >
        > Jeremy
        >
        > On Thursday, March 27, 2025 at 3:36:13 PM UTC-4 Antoine Poinsot wrote:
        >
        >> Hi Chris,
        >>
        >> As i already explained on this very list 2 months ago [0], i don't find the argument for splitting my BIP convincing. On the contrary i think it would be counterproductive as it would create more churn, invite bikeshedding and overall impede progress on this proposal.
        >>
        >>> we've successfully activated multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot.
        >>
        >> Those BIPs had much more content to them. The specifications of the Consensus Cleanup is trivial in comparison: they fit in less than a dozen lines of text when described in details. Splitting them in 4 different BIPs with a single or a couple lines of specifications would just introduce unnecessary overhead.
        >>
        >>> if one of the proposed changes turns out to be controversial, we could remove it without holding up the rest of the improvements.
        >>
        >> First of all, i do not expect to remove any of the mitigations from the BIP at this stage. The fact that each of these mitigations was researched and discussed at length by multiple people over the past year gives me confidence to move forward with every single one of those. Otherwise i would not have proposed this BIP in the first place.
        >>
        >> Now, even if somehow we should drop one of the mitigations from the proposal, having them in separate BIPs does not make that any easier.
        >>
        >>> More active contributors to the project may have stronger opinions on the best approach there.
        >>
        >> Yes.
        >>
        >> Best,
        >> Antoine
        >>
        >> [0] https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpqbtbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-HdOnamw7tUrMtmXc=@protonmail.com
        >> On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart <stewart....@gmail•com> wrote:
        >>
        >>> Hi Antoine,
        >>>
        >>> First off, concept ACK. My concerns are procedural rather than objections to the individual security fixes themselves.
        >>>
        >>> The "Great Consensus Cleanup" is a fantastic brand for communicating these protocol changes to non-technical users. However, since this is a technical forum and we are producing BIPs intended for technical audiences, I believe we should document these changes in separate BIPs.
        >>>
        >>> The proposed security fixes are largely unrelated from a technical standpoint:
        >>>
        >>> -
        >>>
        >>> Timewarp attack mitigation
        >>>
        >>> -
        >>>
        >>> Worst-case block validation constraints
        >>>
        >>> -
        >>>
        >>> Disallowing 64-byte transactions
        >>>
        >>> -
        >>>
        >>> Avoiding duplicate transactions
        >>>
        >>> We should absolutely retain the "Great Consensus Cleanup" branding while independently documenting each security enhancement.
        >>>
        >>> A common concern I’ve heard about splitting this BIP is that deploying soft forks is difficult, so all changes should be bundled together. While soft fork deployment is indeed challenging, we've successfully activated multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the community reaches consensus, we can still deploy all these changes together, even if they are documented separately.
        >>>
        >>> This approach also provides flexibility: if one of the proposed changes turns out to be controversial, we could remove it without holding up the rest of the improvements. Additionally, once these fixes are deployed, there will likely be significant research and documentation to incorporate, and maintaining independent BIPs will make it easier to manage that growth.
        >>>
        >>> I do see merit in implementing all the security fixes in a single PR for Bitcoin Core. More active contributors to the project may have stronger opinions on the best approach there.
        >>>
        >>> -Chris
        >>>
        >>> ---------------------------------------------------------------
        >>>
        >>> On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via Bitcoin Development Mailing List <bitco...@googlegroups•com> wrote:
        >>>
        >>>> Hi everyone,
        >>>>
        >>>> About two months ago i shared an update on this list about my (and others', really) work on the
        >>>> Consensus Cleanup [0]. I am now ready to share a BIP draft for a Consensus Cleanup soft fork.
        >>>>
        >>>> The BIP draft can be found here: https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
        >>>>
        >>>> It includes the following fixes:
        >>>> - a restriction on the timestamp of the first and last blocks of a difficulty adjustment period to
        >>>> address the Timewarp and Murch-Zawy attacks;
        >>>> - a limit on the number of legacy signature operations that may be executed in validating a single
        >>>> transaction to address long block validation times;
        >>>> - making 64 bytes transactions invalid to address weaknesses in the block Merkle tree construction;
        >>>> - mandating coinbase transactions be timelocked to their block height to prevent future transaction
        >>>> duplication without resorting to BIP30 validation.
        >>>>
        >>>> This BIP draws on the 2019 Great Consensus Cleanup proposal from Matt Corallo [1]. A number of
        >>>> people contributed ideas, testing, data or useful discussions. This includes Ava Chow, Matt Corallo,
        >>>> Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony Towns, Greg Sanders, Chris
        >>>> Stewart, Eric Voskuil, @0xb10c and others.
        >>>>
        >>>> Antoine Poinsot
        >>>>
        >>>> [0] https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com
        >>>> [1] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
        >>>>
        >>>> --
        >>>> 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/uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g%3D%40protonmail.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/afedbc69-8042-4fe8-99c2-279173a440f3n%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/2Lz1KjZ8CJ8i_pHJWpGK8lH2UqUbTiLmyRL9qv5hZJkV9pBpXyYL1i288FwsrvtGMPMU-lhFxv0x-sGnUus9RlA8lMCxrwo8TV5ik1yPxfk%3D%40protonmail.com.
        
        [-- Attachment #2: Type: text/html, Size: 17585 bytes --]
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • * Re: [bitcoindev] Consensus Cleanup BIP draft
          2025-03-27 20:45     ` jeremy
          2025-03-27 21:38       ` 'Antoine Poinsot' via Bitcoin Development Mailing List
        @ 2025-03-28  9:23       ` Sjors Provoost
          2025-03-28 11:02         ` Chris Stewart
          2025-03-28 19:53       ` eric
          2 siblings, 1 reply; 16+ messages in thread
        From: Sjors Provoost @ 2025-03-28  9:23 UTC (permalink / raw)
          To: Bitcoin Development Mailing List; +Cc: jeremy
        
        
        > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail•com> het volgende geschreven:
        > 
        > I'm also personally strongly against removing 64-byte transactions. It's a wart in how transactions work, and future upgrades (especially around tx programmability) might integrate very poorly with this kind of edge condition.
        
        Do you have an example in mind where a 64-byte transaction could appear in such a system?
        
        Given the limited space, in particular no room for a public key or signature, I could imagine a burn or anyone-can-spend clause. Those don't have to be exactly 64 bytes. Even if 64 byte transactions are generated by accident, I believe they can be tweaked after the fact (though that claim could use more scrutiny):
        
        https://bitcoin.stackexchange.com/q/125971/4948
        
        If we grant that any smart contract system has to engineer around this "ward", we should also consider how much engineering effort is saved in other smart contract systems by having simpler SPV proofs.
        
        Imo the real ward is the originally broken Merkle tree design. That has required a bunch of engineering all over the place to compensate. Afaik it can only be truly fixed with a hard fork. This seems to be as good as it gets with a soft fork.
        
        - Sjors
        
        -- 
        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/17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D%40sprovoost.nl.
        
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • • * Re: [bitcoindev] Consensus Cleanup BIP draft
            2025-03-28  9:23       ` Sjors Provoost
          @ 2025-03-28 11:02         ` Chris Stewart
            2025-03-28 12:48           ` Sjors Provoost
            0 siblings, 1 reply; 16+ messages in thread
          From: Chris Stewart @ 2025-03-28 11:02 UTC (permalink / raw)
            To: Sjors Provoost; +Cc: Bitcoin Development Mailing List, jeremy
          
          [-- Attachment #1: Type: text/plain, Size: 2997 bytes --]
          
          Hi Sjors,
          
          An example is any segwit transaction that 1 input 1 output that pays to a 2
          byte witness program. Since witness data doesn't count towards the 64 byte
          limit, the witness could be of arbitrary size. This was pointed out
          <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/74?u=chris_stewart_5>
          by garlonicon <https://delvingbitcoin.org/u/garlonicon> on delvingbitcoin.
          This type of witness program is used for pay-to-anchor outputs currently -
          although I don't believe anchor outputs make sense in a 1 input 1 output
          transaction? The author of pay to anchor outputs is aware of this issue
          <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/78?u=chris_stewart_5>,
          but I haven't heard of any further updates since his post on delving.
          
          -Chris
          
          On Fri, Mar 28, 2025 at 4:25 AM Sjors Provoost <sjors@sprovoost•nl> wrote:
          
          >
          > > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail•com> het
          > volgende geschreven:
          > >
          > > I'm also personally strongly against removing 64-byte transactions. It's
          > a wart in how transactions work, and future upgrades (especially around tx
          > programmability) might integrate very poorly with this kind of edge
          > condition.
          >
          > Do you have an example in mind where a 64-byte transaction could appear in
          > such a system?
          >
          > Given the limited space, in particular no room for a public key or
          > signature, I could imagine a burn or anyone-can-spend clause. Those don't
          > have to be exactly 64 bytes. Even if 64 byte transactions are generated by
          > accident, I believe they can be tweaked after the fact (though that claim
          > could use more scrutiny):
          >
          > https://bitcoin.stackexchange.com/q/125971/4948
          >
          > If we grant that any smart contract system has to engineer around this
          > "ward", we should also consider how much engineering effort is saved in
          > other smart contract systems by having simpler SPV proofs.
          >
          > Imo the real ward is the originally broken Merkle tree design. That has
          > required a bunch of engineering all over the place to compensate. Afaik it
          > can only be truly fixed with a hard fork. This seems to be as good as it
          > gets with a soft fork.
          >
          > - Sjors
          >
          > --
          > 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/17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D%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/CAGL6%2BmE8JQGJErgJH03sz8Nzo%2Bwkgx74jgFWp7hFT0MuHiPg_g%40mail.gmail.com.
          
          [-- Attachment #2: Type: text/html, Size: 4240 bytes --]
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • • * Re: [bitcoindev] Consensus Cleanup BIP draft
              2025-03-28 11:02         ` Chris Stewart
            @ 2025-03-28 12:48           ` Sjors Provoost
              2025-03-28 13:54             ` Chris Stewart
              0 siblings, 1 reply; 16+ messages in thread
            From: Sjors Provoost @ 2025-03-28 12:48 UTC (permalink / raw)
              To: Chris Stewart; +Cc: Bitcoin Development Mailing List, jeremy
            
            [-- Attachment #1: Type: text/plain, Size: 2892 bytes --]
            
            Hi Chris,
            
            Thanks for that example.
            
            I also realised that there indeed can exist 64 byte transactions that can't be malleated into a different size (see Stack Exchange link below). The example uses SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, so as long as our hypothetical smart contracting system uses those flags for its burn-all / giveaway-all clauses, then if it produces a 64 byte transaction by mistake, it's recoverable.
            
            But a SIGHASH_ALL could get stuck (can't be confirmed, can't be modified). And IIUC with OP_CTV even a SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, once committed inside a CTV tree, can't be modified.
            
            - Sjors
            
            > Op 28 mrt 2025, om 12:02 heeft Chris Stewart <stewart.chris1234@gmail•com> het volgende geschreven:
            > 
            > Hi Sjors,
            > 
            > An example is any segwit transaction that 1 input 1 output that pays to a 2 byte witness program. Since witness data doesn't count towards the 64 byte limit, the witness could be of arbitrary size. This was pointed out <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/74?u=chris_stewart_5> by garlonicon <https://delvingbitcoin.org/u/garlonicon> on delvingbitcoin. This type of witness program is used for pay-to-anchor outputs currently - although I don't believe anchor outputs make sense in a 1 input 1 output transaction? The author of pay to anchor outputs is aware of this issue <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/78?u=chris_stewart_5>, but I haven't heard of any further updates since his post on delving.
            > 
            > -Chris
            > 
            > On Fri, Mar 28, 2025 at 4:25 AM Sjors Provoost <sjors@sprovoost•nl <mailto:sjors@sprovoost•nl>> wrote:
            >> 
            >> > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail•com <mailto:jeremy.l.rubin@gmail•com>> het volgende geschreven:
            >> > 
            >> > I'm also personally strongly against removing 64-byte transactions. It's a wart in how transactions work, and future upgrades (especially around tx programmability) might integrate very poorly with this kind of edge condition.
            >> 
            >> Do you have an example in mind where a 64-byte transaction could appear in such a system?
            >> 
            >> Given the limited space, in particular no room for a public key or signature, I could imagine a burn or anyone-can-spend clause. Those don't have to be exactly 64 bytes. Even if 64 byte transactions are generated by accident, I believe they can be tweaked after the fact (though that claim could use more scrutiny):
            >> 
            >> https://bitcoin.stackexchange.com/q/125971/4948
            >> 
            
            -- 
            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/80010585-E209-4042-B6F6-5B7DC6675247%40sprovoost.nl.
            
            [-- Attachment #2: Type: text/html, Size: 4209 bytes --]
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

          • • * Re: [bitcoindev] Consensus Cleanup BIP draft
                2025-03-28 12:48           ` Sjors Provoost
              @ 2025-03-28 13:54             ` Chris Stewart
                2025-03-28 14:07               ` Sjors Provoost
                0 siblings, 1 reply; 16+ messages in thread
              From: Chris Stewart @ 2025-03-28 13:54 UTC (permalink / raw)
                To: Sjors Provoost; +Cc: Bitcoin Development Mailing List, jeremy
              
              [-- Attachment #1: Type: text/plain, Size: 4179 bytes --]
              
              *Hi Sjors,*
              
              Sorry to be a bit pedantic here, but I think this distinction is important.
              Are you referring to a pre-SegWit transaction or a SegWit transaction? It’s
              crucial to analyze these separately, as SegWit was designed to solve
              transaction malleability, which affects how we assess backward
              compatibility concerns when disallowing 64-byte transactions.
              
              In the future, it would be helpful to explicitly specify “pre-segwit” or
              “segwit” when discussing potential transactions. In my draft BIP
              <https://github.com/bitcoin/bips/blob/a3d12410d3e3361932e44f34f8420331cf5f9b59/bip-XXXX.mediawiki#backward-compatibility>,
              I differentiate between these two types when evaluating the backward
              compatibility risks of disallowing 64-byte transactions. Additionally, as I
              mentioned earlier (and as I believe Jeremy has also raised concerns about),
              there are potential *future* compatibility issues with segwit transactions.
              
              I'll take a closer look at the Stack Exchange examples and share my
              thoughts there when I have a bit of time.
              
              Thanks for diving into this in detail—I really appreciate it.
              
              *- Chris*
              
              On Fri, Mar 28, 2025 at 7:48 AM Sjors Provoost <sjors@sprovoost•nl> wrote:
              
              > Hi Chris,
              >
              > Thanks for that example.
              >
              > I also realised that there indeed can exist 64 byte transactions that
              > can't be malleated into a different size (see Stack Exchange link below).
              > The example uses SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, so as long as our
              > hypothetical smart contracting system uses those flags for its burn-all /
              > giveaway-all clauses, then if it produces a 64 byte transaction by mistake,
              > it's recoverable.
              >
              > But a SIGHASH_ALL could get stuck (can't be confirmed, can't be modified).
              > And IIUC with OP_CTV even a SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, once
              > committed inside a CTV tree, can't be modified.
              >
              > - Sjors
              >
              > Op 28 mrt 2025, om 12:02 heeft Chris Stewart <stewart.chris1234@gmail•com>
              > het volgende geschreven:
              >
              > Hi Sjors,
              >
              > An example is any segwit transaction that 1 input 1 output that pays to a
              > 2 byte witness program. Since witness data doesn't count towards the 64
              > byte limit, the witness could be of arbitrary size. This was pointed out
              > <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/74?u=chris_stewart_5>
              > by garlonicon <https://delvingbitcoin.org/u/garlonicon> on
              > delvingbitcoin. This type of witness program is used for pay-to-anchor
              > outputs currently - although I don't believe anchor outputs make sense in a
              > 1 input 1 output transaction? The author of pay to anchor outputs is aware
              > of this issue
              > <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/78?u=chris_stewart_5>,
              > but I haven't heard of any further updates since his post on delving.
              >
              > -Chris
              >
              > On Fri, Mar 28, 2025 at 4:25 AM Sjors Provoost <sjors@sprovoost•nl> wrote:
              >
              >>
              >> > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail•com> het
              >> volgende geschreven:
              >> >
              >> > I'm also personally strongly against removing 64-byte transactions.
              >> It's a wart in how transactions work, and future upgrades (especially
              >> around tx programmability) might integrate very poorly with this kind of
              >> edge condition.
              >>
              >> Do you have an example in mind where a 64-byte transaction could appear
              >> in such a system?
              >>
              >> Given the limited space, in particular no room for a public key or
              >> signature, I could imagine a burn or anyone-can-spend clause. Those don't
              >> have to be exactly 64 bytes. Even if 64 byte transactions are generated by
              >> accident, I believe they can be tweaked after the fact (though that claim
              >> could use more scrutiny):
              >>
              >> https://bitcoin.stackexchange.com/q/125971/4948
              >>
              >>
              >
              
              -- 
              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/CAGL6%2BmHuVgWc9ATjRnBz%2Bb7SJyz84La8q9jeM%3Dyiw-Anh%3Da3ag%40mail.gmail.com.
              
              [-- Attachment #2: Type: text/html, Size: 5742 bytes --]
              
              ^ permalink raw reply	[flat|nested] 16+ messages in thread

            • • * Re: [bitcoindev] Consensus Cleanup BIP draft
                  2025-03-28 13:54             ` Chris Stewart
                @ 2025-03-28 14:07               ` Sjors Provoost
                  0 siblings, 0 replies; 16+ messages in thread
                From: Sjors Provoost @ 2025-03-28 14:07 UTC (permalink / raw)
                  To: Chris Stewart; +Cc: Bitcoin Development Mailing List, jeremy
                
                Hi Chris,
                
                Sorry for the confusion. I meant SegWit.
                
                I believe that 64 byte pre-SegWit transactions are always malleable, because there's no space for a signature in the scriptSig. But with SegWit the scriptSig is empty, there could a SIGHASH_ALL signature in the witness.
                
                - Sjors
                
                > Op 28 mrt 2025, om 14:54 heeft Chris Stewart <stewart.chris1234@gmail•com> het volgende geschreven:
                > 
                > Hi Sjors,
                > Sorry to be a bit pedantic here, but I think this distinction is important. Are you referring to a pre-SegWit transaction or a SegWit transaction? It’s crucial to analyze these separately, as SegWit was designed to solve transaction malleability, which affects how we assess backward compatibility concerns when disallowing 64-byte transactions.
                > In the future, it would be helpful to explicitly specify “pre-segwit” or “segwit” when discussing potential transactions. In my draft BIP, I differentiate between these two types when evaluating the backward compatibility risks of disallowing 64-byte transactions. Additionally, as I mentioned earlier (and as I believe Jeremy has also raised concerns about), there are potential future compatibility issues with segwit transactions.
                > I'll take a closer look at the Stack Exchange examples and share my thoughts there when I have a bit of time.
                > 
                
                -- 
                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/8DCD4B60-F1BA-46C4-8594-5CAFB9540128%40sprovoost.nl.
                
                
                ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • * RE: [bitcoindev] Consensus Cleanup BIP draft
          2025-03-27 20:45     ` jeremy
          2025-03-27 21:38       ` 'Antoine Poinsot' via Bitcoin Development Mailing List
          2025-03-28  9:23       ` Sjors Provoost
        @ 2025-03-28 19:53       ` eric
          2025-03-29 11:02         ` Sjors Provoost
          2025-03-31 15:29         ` 'Antoine Poinsot' via Bitcoin Development Mailing List
          2 siblings, 2 replies; 16+ messages in thread
        From: eric @ 2025-03-28 19:53 UTC (permalink / raw)
          To: 'jeremy', 'Bitcoin Development Mailing List'
        
        Hi Jeremy,
        
        > I'm also personally strongly against removing 64-byte transactions. It's a wart
        > in how transactions work, and future upgrades (especially around tx
        > programmability) might integrate very poorly with this kind of edge condition.
        
        I tend to agree. This kind of discontinuity always comes back to bite eventually. That concern should not be dismissed so casually.
        
        But more to the point, it does not solve any of the problems that were originally provided as justification, apart from making it slightly simpler to implement an SPV wallet (no need to get the coinbase tx). This was discussed at very great length here and on delving by myself and others, and I believe that it was fully accepted that the only justification is this SPV question. There are no issues of security or performance for any code, and not even a code simplification for a node. It's a new consensus rule that creates this discontinuity - only to make an SPV wallet very slightly easier to implement. There is no other benefit whatsoever. I want to emphasize this because in the discussion it still seems that people may be holding on to the idea that it provides some other benefit - it doesn't. If people agree that this is a worthwhile trade, I'm not going to lose any sleep over it. But I don't like seeing arguments about consensus being based on implementation details - especially when they are flawed. It feels very much to me that this is what got this issue going (the several rejected arguments about node performance and simplification), and may be in part what's still driving it.
        
        I ACK the single activation concept, but don't accept that a rule should be deployed that would not stand on its own justification.
        
        Also, I do appreciate the work that Antoine and others have done on the set of issues overall.
        
        Best,
        Eric
        
        > On Thursday, March 27, 2025 at 3:36:13 PM UTC-4 Antoine Poinsot wrote:
        > 
        > 
        > 	Hi Chris,
        > 
        > 	As i already explained on this very list 2 months ago [0], i don't find
        > the argument for splitting my BIP convincing. On the contrary i think it would
        > be counterproductive as it would create more churn, invite bikeshedding and
        > overall impede progress on this proposal.
        > 
        > 
        > 		we've successfully activated multiple BIPs within a single soft
        > fork in the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341,
        > BIP342, and BIP343 in Taproot.
        > 
        > 
        > 
        > 	Those BIPs had much more content to them. The specifications of the
        > Consensus Cleanup is trivial in comparison: they fit in less than a dozen lines of
        > text when described in details. Splitting them in 4 different BIPs with a single or
        > a couple lines of specifications would just introduce unnecessary overhead.
        > 
        > 
        > 		if one of the proposed changes turns out to be controversial,
        > we could remove it without holding up the rest of the improvements.
        > 
        > 
        > 
        > 	First of all, i do not expect to remove any of the mitigations from the
        > BIP at this stage. The fact that each of these mitigations was researched and
        > discussed at length by multiple people over the past year gives me confidence
        > to move forward with every single one of those. Otherwise i would not have
        > proposed this BIP in the first place.
        > 
        > 	Now, even if somehow we should drop one of the mitigations from
        > the proposal, having them in separate BIPs does not make that any easier.
        > 
        > 
        > 		More active contributors to the project may have stronger
        > opinions on the best approach there.
        > 
        > 
        > 
        > 	Yes.
        > 
        > 	Best,
        > 	Antoine
        > 
        > 
        > 	[0]
        > https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpq
        > btbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-
        > HdOnamw7tUrMtmXc=@protonmail•com
        > 
        > 	On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart
        > <stewart....@gmail•com> wrote:
        > 
        > 
        > 		Hi Antoine,
        > 
        > 		First off, concept ACK. My concerns are procedural rather than
        > objections to the individual security fixes themselves.
        > 
        > 		The "Great Consensus Cleanup" is a fantastic brand for
        > communicating these protocol changes to non-technical users. However, since
        > this is a technical forum and we are producing BIPs intended for technical
        > audiences, I believe we should document these changes in separate BIPs.
        > 
        > 		The proposed security fixes are largely unrelated from a
        > technical standpoint:
        > 
        > 		1.	Timewarp attack mitigation
        > 
        > 		2.	Worst-case block validation constraints
        > 
        > 		3.	Disallowing 64-byte transactions
        > 
        > 		4.	Avoiding duplicate transactions
        > 
        > 		We should absolutely retain the "Great Consensus Cleanup"
        > branding while independently documenting each security enhancement.
        > 
        > 		A common concern I’ve heard about splitting this BIP is that
        > deploying soft forks is difficult, so all changes should be bundled together.
        > While soft fork deployment is indeed challenging, we've successfully activated
        > multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 in
        > Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the community
        > reaches consensus, we can still deploy all these changes together, even if they
        > are documented separately.
        > 
        > 		This approach also provides flexibility: if one of the proposed
        > changes turns out to be controversial, we could remove it without holding up
        > the rest of the improvements. Additionally, once these fixes are deployed,
        > there will likely be significant research and documentation to incorporate, and
        > maintaining independent BIPs will make it easier to manage that growth.
        > 
        > 		I do see merit in implementing all the security fixes in a single
        > PR for Bitcoin Core. More active contributors to the project may have stronger
        > opinions on the best approach there.
        > 
        > 
        > 
        > 		-Chris
        > 
        > 
        > ________________________________
        > 
        > 
        > 
        > 
        > 
        > 		On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via
        > Bitcoin Development Mailing List <bitco...@googlegroups•com> wrote:
        > 
        > 
        > 			Hi everyone,
        > 
        > 			About two months ago i shared an update on this list
        > about my (and others', really) work on the
        > 			Consensus Cleanup [0]. I am now ready to share a BIP
        > draft for a Consensus Cleanup soft fork.
        > 
        > 			The BIP draft can be found here:
        > https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
        > 
        > 			It includes the following fixes:
        > 			- a restriction on the timestamp of the first and last
        > blocks of a difficulty adjustment period to
        > 			address the Timewarp and Murch-Zawy attacks;
        > 			- a limit on the number of legacy signature operations
        > that may be executed in validating a single
        > 			transaction to address long block validation times;
        > 			- making 64 bytes transactions invalid to address
        > weaknesses in the block Merkle tree construction;
        > 			- mandating coinbase transactions be timelocked to
        > their block height to prevent future transaction
        > 			duplication without resorting to BIP30 validation.
        > 
        > 			This BIP draws on the 2019 Great Consensus Cleanup
        > proposal from Matt Corallo [1]. A number of
        > 			people contributed ideas, testing, data or useful
        > discussions. This includes Ava Chow, Matt Corallo,
        > 			Mark Erhardt, Brian Groll, David A. Harding, Sjors
        > Provoost, Anthony Towns, Greg Sanders, Chris
        > 			Stewart, Eric Voskuil, @0xb10c and others.
        > 
        > 			Antoine Poinsot
        > 
        > 			[0]
        > https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldc
        > ugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnN
        > LRBn3MopuATI=@protonmail•com
        > 			[1]
        > https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197
        > d3eabe661050c2/bip-XXXX.mediawiki
        > 
        > 			--
        > 			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/uDAujRxk4oWnEGYX9lBD3e
        > 0V7a4V4Pd-c4-
        > 2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUc
        > bl7Zne4g%3D%40protonmail.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
        > <mailto:bitcoindev+unsubscribe@googlegroups•com> .
        > To view this discussion visit
        > https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2-
        > 279173a440f3n%40googlegroups.com
        > <https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2-
        > 279173a440f3n%40googlegroups.com?utm_medium=email&utm_source=fo
        > oter> .
        
        
        -- 
        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/065901dba01b%242164fff0%24642effd0%24%40voskuil.org.
        
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • • * Re: [bitcoindev] Consensus Cleanup BIP draft
            2025-03-28 19:53       ` eric
          @ 2025-03-29 11:02         ` Sjors Provoost
            2025-03-31 11:00           ` Anthony Towns
            2025-03-31 15:29         ` 'Antoine Poinsot' via Bitcoin Development Mailing List
            1 sibling, 1 reply; 16+ messages in thread
          From: Sjors Provoost @ 2025-03-29 11:02 UTC (permalink / raw)
            To: eric, 'jeremy', 'Bitcoin Development Mailing List'
          
          On Fri, Mar 28, 2025, at 20:53, eric@voskuil•org wrote:
          > Hi Jeremy,
          >
          >> I'm also personally strongly against removing 64-byte transactions. It's a wart
          
          [...]
          
          > But more to the point, it does not solve any of the problems that were 
          > originally provided as justification, apart from making it slightly 
          > simpler to implement an SPV wallet (no need to get the coinbase tx). 
          
          It's important to keep in mind that "SPV wallet" also includes any kind of automated bridge that requires knowledge of Bitcoin transaction inclusion. What's simple to implement in a rust-bitcoin wallet may be extremely hard in a smart contract. Or maybe it's indeed trivial.
          
          It could be a useful illustration if someone implements such a bridge using any of the proposed covenant op codes, and shows the difference in complexity between having the 64 byte limit and not having it.
          
          I do agree that people should read these other threads to form an opinion on the topic. And the BIP should point to these threads if it doesn't already.
          
          - Sjors
          
          -- 
          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/19f6a854-674a-4e4d-9497-363af306e3a0%40app.fastmail.com.
          
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • • * Re: [bitcoindev] Consensus Cleanup BIP draft
              2025-03-29 11:02         ` Sjors Provoost
            @ 2025-03-31 11:00           ` Anthony Towns
              0 siblings, 0 replies; 16+ messages in thread
            From: Anthony Towns @ 2025-03-31 11:00 UTC (permalink / raw)
              To: Sjors Provoost
              Cc: eric, 'jeremy', 'Bitcoin Development Mailing List'
            
            On Sat, Mar 29, 2025 at 12:02:32PM +0100, Sjors Provoost wrote:
            > On Fri, Mar 28, 2025, at 20:53, eric@voskuil•org wrote:
            > > But more to the point, it does not solve any of the problems that were
            > > originally provided as justification, apart from making it slightly
            > > simpler to implement an SPV wallet (no need to get the coinbase tx).
            > It's important to keep in mind that "SPV wallet" also includes any kind of automated bridge that requires knowledge of Bitcoin transaction inclusion. What's simple to implement in a rust-bitcoin wallet may be extremely hard in a smart contract. Or maybe it's indeed trivial.
            >
            > It could be a useful illustration if someone implements such a bridge using any of the proposed covenant op codes, and shows the difference in complexity between having the 64 byte limit and not having it.
            
            I think it's almost certainly easy to just avoid being concerned with 64
            byte transactions for a bridge:
            
             * for txs moving value off of bitcoin, the bridge will certainly want
               the funds secured in some output, so that will naturally be more than
               4 bytes;
            
             * for txs moving value back to bitcoin, there'll usually be two outputs
               (one for amount being moved, one for change), and almost always, the
               recipient of the funds will want them secured; either of which gives
               a more than 64 byte tx.  it's only if the bridge explicitly supports
               burning funds (entirely, or to fees) and is precisely burning a full
               utxo with no change; but in that case the bridge can just require
               the output be an op_return that pushes three or more bytes of data.
            
             * additionally, if the bridge doesn't manage fees in-band (with bridged
               funds), but does it out of band via a p2a output, that also ensures
               that none of its txs will be 64 bytes.
            
            Similar consideraions mostly apply to SPV wallets as well -- if you're
            trying to trick someone into believing they've received some funds, you'll
            need to supply a tx that includes an output that matches their wallet,
            which will be more than 4 bytes, so won't match a 64-byte tx; and if
            you're trying to trick them into thinking they've burnt some of their
            funds, you'll need to get a "64-bit tx" that includes a txid/vout pair
            that matches one of their utxos, which is roughly a 256-bit collision,
            so should be cryptographically hard...
            
            Cheers,
            aj
            
            -- 
            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/Z-p1uWpMV4cZul36%40erisian.com.au.
            
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • * RE: [bitcoindev] Consensus Cleanup BIP draft
            2025-03-28 19:53       ` eric
            2025-03-29 11:02         ` Sjors Provoost
          @ 2025-03-31 15:29         ` 'Antoine Poinsot' via Bitcoin Development Mailing List
            2025-03-31 20:09           ` eric
            1 sibling, 1 reply; 16+ messages in thread
          From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-31 15:29 UTC (permalink / raw)
            To: eric; +Cc: 'Bitcoin Development Mailing List'
          
          Hi Eric,
          
          Thanks for chiming in.
          
          > This kind of discontinuity always comes back to bite eventually. That concern should not be dismissed so casually.
          
          I don't think i've dismissed your concern when you brought this up last year. In fact i link to my summary of arguments on both sides of this debate in the BIP: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41.
          
          > But more to the point, it does not solve any of the problems that were originally provided as justification, apart from making it slightly simpler to implement an SPV wallet (no need to get the coinbase tx).
          
          I did provide an incorrect motivation at some point (caching), and appreciate your correction on this. But the main original motivation for invalidating 64 bytes transactions was always to get rid of the footgun for SPV verifiers. For instance see Matt's original BIP: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki#discussion.
          
          And as Sjors points out SPV verifiers shouldn't be reduced to only SPV wallets.
          
          > If people agree that this is a worthwhile trade, I'm not going to lose any sleep over it.
          
          This is my position and the reason why i included it in my BIP. Of course introducing this discontinuity is pretty ugly. I just believe it's less bad than keeping the weakness that 64 bytes transaction introduce.
          
          I am also not married to the idea. In fact, i think it's one of the less important fixes from the proposal. But as things stand i think it's preferable to include it. Of course i am happy to reconsider in the face of new arguments and/or data.
          
          Best,
          Antoine
          
          On Friday, March 28th, 2025 at 3:53 PM, eric@voskuil•org <eric@voskuil•org> wrote:
          
          > 
          > 
          > Hi Jeremy,
          > 
          > > I'm also personally strongly against removing 64-byte transactions. It's a wart
          > > in how transactions work, and future upgrades (especially around tx
          > > programmability) might integrate very poorly with this kind of edge condition.
          > 
          > 
          > I tend to agree. This kind of discontinuity always comes back to bite eventually. That concern should not be dismissed so casually.
          > 
          > But more to the point, it does not solve any of the problems that were originally provided as justification, apart from making it slightly simpler to implement an SPV wallet (no need to get the coinbase tx). This was discussed at very great length here and on delving by myself and others, and I believe that it was fully accepted that the only justification is this SPV question. There are no issues of security or performance for any code, and not even a code simplification for a node. It's a new consensus rule that creates this discontinuity - only to make an SPV wallet very slightly easier to implement. There is no other benefit whatsoever. I want to emphasize this because in the discussion it still seems that people may be holding on to the idea that it provides some other benefit - it doesn't. If people agree that this is a worthwhile trade, I'm not going to lose any sleep over it. But I don't like seeing arguments about consensus being based on implementation details - especially when they are flawed. It feels very much to me that this is what got this issue going (the several rejected arguments about node performance and simplification), and may be in part what's still driving it.
          > 
          > I ACK the single activation concept, but don't accept that a rule should be deployed that would not stand on its own justification.
          > 
          > Also, I do appreciate the work that Antoine and others have done on the set of issues overall.
          > 
          > Best,
          > Eric
          > 
          > > On Thursday, March 27, 2025 at 3:36:13 PM UTC-4 Antoine Poinsot wrote:
          > > 
          > > Hi Chris,
          > > 
          > > As i already explained on this very list 2 months ago [0], i don't find
          > > the argument for splitting my BIP convincing. On the contrary i think it would
          > > be counterproductive as it would create more churn, invite bikeshedding and
          > > overall impede progress on this proposal.
          > > 
          > > we've successfully activated multiple BIPs within a single soft
          > > fork in the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341,
          > > BIP342, and BIP343 in Taproot.
          > > 
          > > Those BIPs had much more content to them. The specifications of the
          > > Consensus Cleanup is trivial in comparison: they fit in less than a dozen lines of
          > > text when described in details. Splitting them in 4 different BIPs with a single or
          > > a couple lines of specifications would just introduce unnecessary overhead.
          > > 
          > > if one of the proposed changes turns out to be controversial,
          > > we could remove it without holding up the rest of the improvements.
          > > 
          > > First of all, i do not expect to remove any of the mitigations from the
          > > BIP at this stage. The fact that each of these mitigations was researched and
          > > discussed at length by multiple people over the past year gives me confidence
          > > to move forward with every single one of those. Otherwise i would not have
          > > proposed this BIP in the first place.
          > > 
          > > Now, even if somehow we should drop one of the mitigations from
          > > the proposal, having them in separate BIPs does not make that any easier.
          > > 
          > > More active contributors to the project may have stronger
          > > opinions on the best approach there.
          > > 
          > > Yes.
          > > 
          > > Best,
          > > Antoine
          > > 
          > > [0]
          > > https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpq
          > > btbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-
          > > HdOnamw7tUrMtmXc=@protonmail•com
          > > 
          > > On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart
          > > stewart....@gmail•com wrote:
          > > 
          > > Hi Antoine,
          > > 
          > > First off, concept ACK. My concerns are procedural rather than
          > > objections to the individual security fixes themselves.
          > > 
          > > The "Great Consensus Cleanup" is a fantastic brand for
          > > communicating these protocol changes to non-technical users. However, since
          > > this is a technical forum and we are producing BIPs intended for technical
          > > audiences, I believe we should document these changes in separate BIPs.
          > > 
          > > The proposed security fixes are largely unrelated from a
          > > technical standpoint:
          > > 
          > > 1. Timewarp attack mitigation
          > > 
          > > 2. Worst-case block validation constraints
          > > 
          > > 3. Disallowing 64-byte transactions
          > > 
          > > 4. Avoiding duplicate transactions
          > > 
          > > We should absolutely retain the "Great Consensus Cleanup"
          > > branding while independently documenting each security enhancement.
          > > 
          > > A common concern I’ve heard about splitting this BIP is that
          > > deploying soft forks is difficult, so all changes should be bundled together.
          > > While soft fork deployment is indeed challenging, we've successfully activated
          > > multiple BIPs within a single soft fork in the past—e.g., BIP141 and BIP143 in
          > > Segwit, as well as BIP341, BIP342, and BIP343 in Taproot. If the community
          > > reaches consensus, we can still deploy all these changes together, even if they
          > > are documented separately.
          > > 
          > > This approach also provides flexibility: if one of the proposed
          > > changes turns out to be controversial, we could remove it without holding up
          > > the rest of the improvements. Additionally, once these fixes are deployed,
          > > there will likely be significant research and documentation to incorporate, and
          > > maintaining independent BIPs will make it easier to manage that growth.
          > > 
          > > I do see merit in implementing all the security fixes in a single
          > > PR for Bitcoin Core. More active contributors to the project may have stronger
          > > opinions on the best approach there.
          > > 
          > > -Chris
          > > 
          > > ________________________________
          > > 
          > > On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via
          > > Bitcoin Development Mailing List bitco...@googlegroups•com wrote:
          > > 
          > > Hi everyone,
          > > 
          > > About two months ago i shared an update on this list
          > > about my (and others', really) work on the
          > > Consensus Cleanup [0]. I am now ready to share a BIP
          > > draft for a Consensus Cleanup soft fork.
          > > 
          > > The BIP draft can be found here:
          > > https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
          > > 
          > > It includes the following fixes:
          > > - a restriction on the timestamp of the first and last
          > > blocks of a difficulty adjustment period to
          > > address the Timewarp and Murch-Zawy attacks;
          > > - a limit on the number of legacy signature operations
          > > that may be executed in validating a single
          > > transaction to address long block validation times;
          > > - making 64 bytes transactions invalid to address
          > > weaknesses in the block Merkle tree construction;
          > > - mandating coinbase transactions be timelocked to
          > > their block height to prevent future transaction
          > > duplication without resorting to BIP30 validation.
          > > 
          > > This BIP draws on the 2019 Great Consensus Cleanup
          > > proposal from Matt Corallo [1]. A number of
          > > people contributed ideas, testing, data or useful
          > > discussions. This includes Ava Chow, Matt Corallo,
          > > Mark Erhardt, Brian Groll, David A. Harding, Sjors
          > > Provoost, Anthony Towns, Greg Sanders, Chris
          > > Stewart, Eric Voskuil, @0xb10c and others.
          > > 
          > > Antoine Poinsot
          > > 
          > > [0]
          > > https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldc
          > > ugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnN
          > > LRBn3MopuATI=@protonmail•com
          > > [1]
          > > https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197
          > > d3eabe661050c2/bip-XXXX.mediawiki
          > > 
          > > --
          > > 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/uDAujRxk4oWnEGYX9lBD3e
          > > 0V7a4V4Pd-c4-
          > > 2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUc
          > > bl7Zne4g%3D%40protonmail.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
          > > mailto:bitcoindev+unsubscribe@googlegroups•com .
          > > To view this discussion visit
          > > https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2-
          > > 279173a440f3n%40googlegroups.com
          > > <https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-99c2-
          > > 279173a440f3n%40googlegroups.com?utm_medium=email&utm_source=fo
          > > oter> .
          > 
          > 
          > 
          > --
          > 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/065901dba01b%242164fff0%24642effd0%24%40voskuil.org.
          
          -- 
          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/xusxPfCMTmIMZ4dvGoG4SvPH3kg1vFSq3Hrk0GFHVKJCSC9aojyeyY6fUkwq_3PRhiHowSrT3B2KbJXMT6PENmOH1dvwYve8ofwZSN6QpKc%3D%40protonmail.com.
          
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • • * RE: [bitcoindev] Consensus Cleanup BIP draft
              2025-03-31 15:29         ` 'Antoine Poinsot' via Bitcoin Development Mailing List
            @ 2025-03-31 20:09           ` eric
              0 siblings, 0 replies; 16+ messages in thread
            From: eric @ 2025-03-31 20:09 UTC (permalink / raw)
              To: 'Antoine Poinsot'; +Cc: 'Bitcoin Development Mailing List'
            
            > Hi Eric,
            > 
            > Thanks for chiming in.
            
            Certainly, thank you as well for your work on this.
            
            > > This kind of discontinuity always comes back to bite eventually. That concern
            > should not be dismissed so casually.
            > 
            > I don't think i've dismissed your concern when you brought this up last year. In
            > fact i link to my summary of arguments on both sides of this debate in the BIP:
            > https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41.
            
            You have been fair. I don't mean to imply that you dismissed the points I raised. But it doesn't seem to me that this discontinuity has been given much weight. This was the issue that Jeremy raised.
            
            >>> It's a wart in how transactions work, and future upgrades (especially around tx programmability) might integrate very poorly with this kind of edge condition.
            
            From my experience every condition magnifies complexity over time. We are talking about moving a condition from SPV clients into consensus.
            
            > > But more to the point, it does not solve any of the problems that were
            > originally provided as justification, apart from making it slightly simpler to
            > implement an SPV wallet (no need to get the coinbase tx).
            > 
            > I did provide an incorrect motivation at some point (caching), and appreciate
            > your correction on this. But the main original motivation for invalidating 64
            > bytes transactions was always to get rid of the footgun for SPV verifiers...
            
            This thread contains the technical discussion on the question:
            https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/MsOdTqYyCwAJ
            
            Your early response to my query listed:
            (1) make node invalidity caching more performant.
            (2) preclude the need for SPV clients to get the coinbase proof.
            (3) "Finally, it would get rid of a large footgun in general. Certainly, unique block hashes would be a useful property for Bitcoin to have. It's not far-fetched to expect current or future Bitcoin-related software to rely on this."
            
            The tradeoff was described as:
            "Outlawing 64-bytes transactions is also a very narrow and straightforward change, with trivial confiscatory effect as any 64-bytes transactions would either be unspendable or an anyone-can-spend. Therefore i believe the benefits of making them illegal outweigh the costs."
            
            I realize there was a lot of subsequent discussion , and that you accepted that 1 and 3 would not in fact be benefits of the fork. But the third objective was not limited to caching. One of my concerns was that people were being influenced by these objectives that would not in fact be achieved or even advanced.
            
            > And as Sjors points out SPV verifiers shouldn't be reduced to only SPV wallets.
            
            Let's say SPV clients. I wasn't making an intentional distinction except between consensus and non-consensus code.
            
            > > If people agree that this is a worthwhile trade, I'm not going to lose any sleep
            > over it.
            > 
            > This is my position and the reason why i included it in my BIP. Of course
            > introducing this discontinuity is pretty ugly. I just believe it's less bad than
            > keeping the weakness that 64 bytes transaction introduce.
            > 
            > I am also not married to the idea. In fact, i think it's one of the less important
            > fixes from the proposal. But as things stand i think it's preferable to include it.
            > Of course i am happy to reconsider in the face of new arguments and/or data.
            > 
            > Best,
            > Antoine
            
            Best,
            Eirc
            
            > On Friday, March 28th, 2025 at 3:53 PM, eric@voskuil•org <eric@voskuil•org>
            > wrote:
            > 
            > >
            > >
            > > Hi Jeremy,
            > >
            > > > I'm also personally strongly against removing 64-byte transactions.
            > > > It's a wart in how transactions work, and future upgrades
            > > > (especially around tx
            > > > programmability) might integrate very poorly with this kind of edge
            > condition.
            > >
            > >
            > > I tend to agree. This kind of discontinuity always comes back to bite
            > eventually. That concern should not be dismissed so casually.
            > >
            > > But more to the point, it does not solve any of the problems that were
            > originally provided as justification, apart from making it slightly simpler to
            > implement an SPV wallet (no need to get the coinbase tx). This was discussed
            > at very great length here and on delving by myself and others, and I believe
            > that it was fully accepted that the only justification is this SPV question. There
            > are no issues of security or performance for any code, and not even a code
            > simplification for a node. It's a new consensus rule that creates this
            > discontinuity - only to make an SPV wallet very slightly easier to implement.
            > There is no other benefit whatsoever. I want to emphasize this because in the
            > discussion it still seems that people may be holding on to the idea that it
            > provides some other benefit - it doesn't. If people agree that this is a
            > worthwhile trade, I'm not going to lose any sleep over it. But I don't like seeing
            > arguments about consensus being based on implementation details -
            > especially when they are flawed. It feels very much to me that this is what got
            > this issue going (the several rejected arguments about node performance and
            > simplification), and may be in part what's still driving it.
            > >
            > > I ACK the single activation concept, but don't accept that a rule should be
            > deployed that would not stand on its own justification.
            > >
            > > Also, I do appreciate the work that Antoine and others have done on the set
            > of issues overall.
            > >
            > > Best,
            > > Eric
            > >
            > > > On Thursday, March 27, 2025 at 3:36:13 PM UTC-4 Antoine Poinsot
            > wrote:
            > > >
            > > > Hi Chris,
            > > >
            > > > As i already explained on this very list 2 months ago [0], i don't
            > > > find the argument for splitting my BIP convincing. On the contrary i
            > > > think it would be counterproductive as it would create more churn,
            > > > invite bikeshedding and overall impede progress on this proposal.
            > > >
            > > > we've successfully activated multiple BIPs within a single soft fork
            > > > in the past—e.g., BIP141 and BIP143 in Segwit, as well as BIP341,
            > > > BIP342, and BIP343 in Taproot.
            > > >
            > > > Those BIPs had much more content to them. The specifications of the
            > > > Consensus Cleanup is trivial in comparison: they fit in less than a
            > > > dozen lines of text when described in details. Splitting them in 4
            > > > different BIPs with a single or a couple lines of specifications would just
            > introduce unnecessary overhead.
            > > >
            > > > if one of the proposed changes turns out to be controversial, we
            > > > could remove it without holding up the rest of the improvements.
            > > >
            > > > First of all, i do not expect to remove any of the mitigations from
            > > > the BIP at this stage. The fact that each of these mitigations was
            > > > researched and discussed at length by multiple people over the past
            > > > year gives me confidence to move forward with every single one of
            > > > those. Otherwise i would not have proposed this BIP in the first place.
            > > >
            > > > Now, even if somehow we should drop one of the mitigations from the
            > > > proposal, having them in separate BIPs does not make that any easier.
            > > >
            > > > More active contributors to the project may have stronger opinions
            > > > on the best approach there.
            > > >
            > > > Yes.
            > > >
            > > > Best,
            > > > Antoine
            > > >
            > > > [0]
            > > >
            > https://gnusha.org/pi/bitcoindev/mm_NvE4votqtjm455I3AmdrLOTzwgfFpq
            > > > btbFFNy0Zf2PywGt220MXfn76it60q_kbnS9Rw97cv6XzqogNgQMfIXi6-
            > > > HdOnamw7tUrMtmXc=@protonmail•com
            > > >
            > > > On Thursday, March 27th, 2025 at 6:46 AM, Chris Stewart
            > > > stewart....@gmail•com wrote:
            > > >
            > > > Hi Antoine,
            > > >
            > > > First off, concept ACK. My concerns are procedural rather than
            > > > objections to the individual security fixes themselves.
            > > >
            > > > The "Great Consensus Cleanup" is a fantastic brand for communicating
            > > > these protocol changes to non-technical users. However, since this
            > > > is a technical forum and we are producing BIPs intended for
            > > > technical audiences, I believe we should document these changes in
            > separate BIPs.
            > > >
            > > > The proposed security fixes are largely unrelated from a technical
            > > > standpoint:
            > > >
            > > > 1. Timewarp attack mitigation
            > > >
            > > > 2. Worst-case block validation constraints
            > > >
            > > > 3. Disallowing 64-byte transactions
            > > >
            > > > 4. Avoiding duplicate transactions
            > > >
            > > > We should absolutely retain the "Great Consensus Cleanup"
            > > > branding while independently documenting each security enhancement.
            > > >
            > > > A common concern I’ve heard about splitting this BIP is that
            > > > deploying soft forks is difficult, so all changes should be bundled together.
            > > > While soft fork deployment is indeed challenging, we've successfully
            > > > activated multiple BIPs within a single soft fork in the past—e.g.,
            > > > BIP141 and BIP143 in Segwit, as well as BIP341, BIP342, and BIP343
            > > > in Taproot. If the community reaches consensus, we can still deploy
            > > > all these changes together, even if they are documented separately.
            > > >
            > > > This approach also provides flexibility: if one of the proposed
            > > > changes turns out to be controversial, we could remove it without
            > > > holding up the rest of the improvements. Additionally, once these
            > > > fixes are deployed, there will likely be significant research and
            > > > documentation to incorporate, and maintaining independent BIPs will
            > make it easier to manage that growth.
            > > >
            > > > I do see merit in implementing all the security fixes in a single PR
            > > > for Bitcoin Core. More active contributors to the project may have
            > > > stronger opinions on the best approach there.
            > > >
            > > > -Chris
            > > >
            > > > ________________________________
            > > >
            > > > On Wed, Mar 26, 2025 at 1:23 PM 'Antoine Poinsot' via Bitcoin
            > > > Development Mailing List bitco...@googlegroups•com wrote:
            > > >
            > > > Hi everyone,
            > > >
            > > > About two months ago i shared an update on this list about my (and
            > > > others', really) work on the Consensus Cleanup [0]. I am now ready
            > > > to share a BIP draft for a Consensus Cleanup soft fork.
            > > >
            > > > The BIP draft can be found here:
            > > > https://github.com/darosior/bips/blob/consensus_cleanup/bip-cc.md
            > > >
            > > > It includes the following fixes:
            > > > - a restriction on the timestamp of the first and last blocks of a
            > > > difficulty adjustment period to address the Timewarp and Murch-Zawy
            > > > attacks;
            > > > - a limit on the number of legacy signature operations that may be
            > > > executed in validating a single transaction to address long block
            > > > validation times;
            > > > - making 64 bytes transactions invalid to address weaknesses in the
            > > > block Merkle tree construction;
            > > > - mandating coinbase transactions be timelocked to their block
            > > > height to prevent future transaction duplication without resorting
            > > > to BIP30 validation.
            > > >
            > > > This BIP draws on the 2019 Great Consensus Cleanup proposal from
            > > > Matt Corallo [1]. A number of people contributed ideas, testing,
            > > > data or useful discussions. This includes Ava Chow, Matt Corallo,
            > > > Mark Erhardt, Brian Groll, David A. Harding, Sjors Provoost, Anthony
            > > > Towns, Greg Sanders, Chris Stewart, Eric Voskuil, @0xb10c and
            > > > others.
            > > >
            > > > Antoine Poinsot
            > > >
            > > > [0]
            > > >
            > https://gnusha.org/pi/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldc
            > > >
            > ugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnN
            > > > LRBn3MopuATI=@protonmail•com
            > > > [1]
            > > >
            > https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197
            > > > d3eabe661050c2/bip-XXXX.mediawiki
            > > >
            > > > --
            > > > 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/uDAujRxk4oWnEGYX9lBD3e
            > > > 0V7a4V4Pd-c4-
            > > >
            > 2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUc
            > > > bl7Zne4g%3D%40protonmail.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
            > > > mailto:bitcoindev+unsubscribe@googlegroups•com .
            > > > To view this discussion visit
            > > > https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-
            > 99c2
            > > > -
            > > > 279173a440f3n%40googlegroups.com
            > > > <https://groups.google.com/d/msgid/bitcoindev/afedbc69-8042-4fe8-
            > 99c
            > > > 2-
            > 279173a440f3n%40googlegroups.com?utm_medium=email&utm_source=fo
            > > > oter> .
            > >
            > >
            > >
            > > --
            > > 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/065901dba01b%242164fff
            > 0%24642effd0%24%40voskuil.org.
            
            -- 
            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/009d01dba278%24dcde1a00%24969a4e00%24%40voskuil.org.
            
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2025-03-31 20:50 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-03-26 17:14 [bitcoindev] Consensus Cleanup BIP draft 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-27 10:46 ` Chris Stewart
2025-03-27 17:54   ` /dev /fd0
2025-03-27 19:05   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-27 20:45     ` jeremy
2025-03-27 21:38       ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-28  9:23       ` Sjors Provoost
2025-03-28 11:02         ` Chris Stewart
2025-03-28 12:48           ` Sjors Provoost
2025-03-28 13:54             ` Chris Stewart
2025-03-28 14:07               ` Sjors Provoost
2025-03-28 19:53       ` eric
2025-03-29 11:02         ` Sjors Provoost
2025-03-31 11:00           ` Anthony Towns
2025-03-31 15:29         ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-31 20:09           ` eric

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