Hello devs, Writing this post to do a summary of where from my viewpoint BIP 54 is, in terms of technical readiness, and what are the remaining steps to be done, to move it toward its technical finalization and after that to activation. Indeed, it goes without saying it's representing my viewpoint only. Back on the chronological timeline, the great consensus cleanup was put back on the table by Poinsot at the end of '23 and beginning of '24 [0]. The aim of the consensus changes is to fix long known security issues among bitcoin protocol devs, even if there is a divergence of viewpoints among them on their severities, and necessity of a consensus patch. Those issues are (a) the timewarp attack, (b) the long block validation time arising for pre-segwit scripts, (c) the merkle tree malleability with 64-byte transactions and (d) the possibility of duplicate coinbase transactions. There were numerous design discussions on the best way to solve each issue [1]. During those discussions, it has been made the point, that it might be necessary to fix more advanced variants of some attack, notably the Murch-Zawy one [2]. In parallel, investigations were made on the private Delving Bitcoin thread on the worst-case evaluations for the long block validation time. Early '25, a BIP draft was proposed to the community [3]. It turns out that the new rule to remove 64-byte transactions was (and is still) the most argued against, by some devs. After those conversations, a reference implementation was proposed with test vectors in late '25 [4]. The work was done to address more open technical concerns from different people beginning of '26, notably on the encoding of the height in the coinbase transaction nlocktime [5]. Public demo of the severity of the long block validation time was made on signet [6]. More conversations still arised about the 64-byte transactions [7]. Those are the main elements on the design conversations about BIP 54 that I can remember from my memory, while of course there are more design conversations that did happen not listed here. A pull request on bitcoin core has been opened to implement BIP54 and it is currently under review and testing [8]. There is also ongoing work in btcd to implement the BIP and exercise inter-compatibility [9]. I think there is no ongoing implementation for libbitcoin, though as said I would be willing to contribute to the review of one there. Moving BIP54 past the finish line, in my view, would necessitate resolving the open technical conservations, especially on the disagreement about the 64 bye transactions. Apart from the high level technical conversations calling for progress, more review and testing of the reference implementation is obviously needed. More sound review and testing is always better, higher we set the technical bar, better we're while staying realistic on the process. Testing inter-compatibility with one or more other implementations is likely also valuable, to assert there is no shortcoming with the design. Beyond, though that's might be my personal view only, some parts of the BIP would be better to be more documented for any wallet or off-chain protocol, in function of what they're doing it's good for them to be aware of the proposed new 2500 pre-segwit script tx limit, and the 64 byte outlawing rule if it slips in. Overall, I think it's good to invite skilled eyes that wish to do so to go over the full conceptual BIP 54 design, what they agree with, what they disagree with, what could be improved and goes to publish their grounded analysis on their personal blog, or whatever. A standard of review that was echoed in the past [10]. Doing more real-live testing of the vulnerabilities like it has been done on signet might be very valuable again. Apart of the activation logic, of which the conversation can be deferred later on, what else would be technically valuable to advance the conversation ? Minding all of that, and with previous experience of the design, review and activation cycle of the schnorr / taproot change, it might sounds realistic to slowly start to think about an activation of BIP 54 during S2 2027. Why not if the community consensus is present by then, and of course no "force majeure" ou sh*t hit the fan too much (as it happens in the bitcoin world). I'm only speaking for myself, so everyone else in the (bitcoin) world is free to respectfully disagree with the present viewpoint. Hopefully, at least it is useful to advance the conversation and not being the BIP champion it's easier for me to do such a call. Looking on a long term perspective, there are other consensus changes that will be likely very also valuable in the future be it post quantum or other security fixes, and imo it's better as a community we don't sleep on them. Cheers, Antoine OTS hash: dbc7c36dbce85e4885b4d140bb90a1d775176b7ec60753d02a655e42418062bb [0] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo [1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 [2] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062 [3] https://groups.google.com/g/bitcoindev/c/0tSvml90Qcw [4] https://groups.google.com/g/bitcoindev/c/1XEtmIS_XRc [5] https://groups.google.com/g/bitcoindev/c/6TTlDwP2OQg [6] https://delvingbitcoin.org/t/consensus-cleanup-demo-of-slow-blocks-on-signet/2367 [7] https://groups.google.com/g/bitcoindev/c/iCuq6bFKt5Y [8] https://github.com/bitcoin/bips/pull/1800 [9] https://github.com/btcsuite/btcd/pull/2537 [10] https://gnusha.org/pi/bitcoindev/CAGpPWDbbZ7PEpr4iwYwBn+5QcjjCx8qmTZVB98i2Z=UwDfwaTQ@mail.gmail.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/CALZpt%2BGwkE1gH2-yrJXt%3DoqkrYR_ubdrMur0PG6aZvziJCHMLg%40mail.gmail.com.