From: <eric@voskuil•org>
To: "'Antoine Poinsot'" <darosior@protonmail•com>
Cc: "'Bitcoin Development Mailing List'" <bitcoindev@googlegroups.com>
Subject: RE: [bitcoindev] Consensus Cleanup BIP draft
Date: Mon, 31 Mar 2025 16:09:51 -0400 [thread overview]
Message-ID: <009d01dba278$dcde1a00$969a4e00$@voskuil.org> (raw)
In-Reply-To: <xusxPfCMTmIMZ4dvGoG4SvPH3kg1vFSq3Hrk0GFHVKJCSC9aojyeyY6fUkwq_3PRhiHowSrT3B2KbJXMT6PENmOH1dvwYve8ofwZSN6QpKc=@protonmail.com>
> 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.
prev parent reply other threads:[~2025-03-31 20:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 17:14 '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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='009d01dba278$dcde1a00$969a4e00$@voskuil.org' \
--to=eric@voskuil$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox