Hello, > It's a fine line to tread, because on the one hand you do not want to give away the details of how to optimise the attack (whether for maximum profit or for maximum impact), but on the other hand i do think it's necessary to provide some amount of publicly verifiable information to support a soft fork activation proposal. Agree here it's a fine line and there is no good answer. It's the same problem every time a covert fix for a severe bug has to be developed and disseminated. And from what I aware of, even for open source kernels, where fixes processes have been broken in for 20+ years, they are not doing that much better... > After that, i split the 6 slow-to-validate transactions into smaller BIP 54 compatible ones. When you say "splitting" I guess you mean crafting transactions spending the same preparation outputs, though for example with less sig ops in the scriptpubkey to have them passing the new MAX_TX_LEGACY_SIGOPS, though the txid:index spent are staying the same. That BIP54 is reducing the value transferred throughput per byte of tx when you're consuming legacy inputs, I think that's a fine trade-off (-- I guess other questions and observations can be made on the delving thread). Going further, in my memory the taproot structured review back in 2019 [0] was a good initiative to have a lot of eyes engaging in the review process of those consensus changes. While it might be harder those days to have everyone fitting in a IRC channel due to the growth of the ecosystem (...?), I wonder if an alternative could be to have a handbook explaining how to test on a regtest pre / after BIP 54 fixes each one of the fix (difficulty adjustement, long block validation time, merkle tree malleability, duplicate coinbase txn). People can be full-node operator, doesn't necessarily means they have the skills to write their own python tests to check specific behaviors. The handbook is just an idea, but I'm sure people would love to go through at their local bitcoin meetups. And somehow, I believe for consensus changes, it's good to do the work of building legitimacy (i.e lowering the bar for anyone to reproduce the tests ?). Best, (the other) Antoine OTS hash: c5ca45485b8362dfaa20516192395b051706ac06c9e975176be4de8665928ef9 [0] https://github.com/ajtowns/taproot-review Le Monday, March 30, 2026 à 8:40:21 PM UTC+1, Antoine Poinsot a écrit : > My approach so far has been to share all details in the semi-private > Delving thread that is accessible to a number of experts who would be able > to figure it out on their own anyway, and to share a demonstration of an > expensive-but-far-from-worst block publicly. > > > Anthony Towns and i performed such a demo last week on Signet. > > I created preparation outputs for 6 transactions that are slow to > validate. How slow depends on the machine, my tests show 4 seconds per > block on modern hardware, about 20 seconds on a mid-range server, and over > a minute on a RPi 4B. AJ reports it took a cheap VPS about 5 minutes to > validate each block during the live demo. > > AJ mined 6 blocks in a row containing those transactions, and then reorged > them out. This allows anyone who was running a Bitcoin Core Signet node at > the time to observe the slowish blocks, without imposing an IBD cost to all > future nodes. It goes without saying that anyone running Bitcoin > Inquisition >= 29.2 instead would observe their nodes rejecting those > blocks, since BIP 54 makes them invalid. > > After that, i split the 6 slow-to-validate transactions into smaller BIP > 54 compatible ones. AJ mined them in 6 more blocks that spend the same set > of inputs that the slow blocks did. This is a demonstration that BIP 54 > only precludes batching too many legacy inputs, to not exacerbate quadratic > behaviours in transaction validation, but spending those same inputs in > multiple transactions is entirely fine. > > More details on the demo are available here: > https://bnoc.xyz/t/slowish-blocks-on-signet/100. Thanks to b10c and Emzy > for participating and sharing observations. > > Here are the hashes of the stale slowish blocks: > > - 00000000d9338f3251ebb0dc01afebf34b38a2bafaf1376ef9e26e02eadb0c64 > - 00000006048ed6cfedbc6249c5eb82616a4a90cb35c76127af7a40e3198736e1 > - 00000013fb4596b358dd07ede7ef18c57a64e4a6fc0b33944bb86b91f0e74b32 > - 00000007326c42ef17ee090f758ba328954f24313648dc0971b7b33b165427e7 > - 00000002a129891c57504b01e855d29e8e4debc90a12eb092a1afe83e87b13f0 > - 0000000cd04ef18d4a43fa7fc093b8c3a6d29685d899f29e20373bfd04bab78d > > > Here is a tentative (unsure if it'll make it through to the list) > screenshot of a peer observer > instance b10c had deployed for the occasion, right after the reorg. Node 01 > runs Bitcoin Core v31.0rc1 Signet and node 02 runs Bitcoin Inquisition > v29.2. > [image: image.png] > > Antoine Poinsot > > On Wednesday, March 11th, 2026 at 11:27 AM, 'Antoine Poinsot' via Bitcoin > Development Mailing List wrote: > > I share this concern, which is why i only shared details about this in the > (semi-)private Delving thread to this effect: > https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711. > > The testing for quality assurance has already been performed as part of > the investigation into the various techniques and possible mitigations. > Additional testing is always valuable, but the primary goal of a public > demonstration for this would be to help build consensus. > > It's a fine line to tread, because on the one hand you do not want to give > away the details of how to optimise the attack (whether for maximum profit > or for maximum impact), but on the other hand i do think it's necessary to > provide some amount of publicly verifiable information to support a soft > fork activation proposal. > > My approach so far has been to share all details in the semi-private > Delving thread that is accessible to a number of experts who would be able > to figure it out on their own anyway, and to share a demonstration of an > expensive-but-far-from-worst block publicly. This allows anyone to check > for themselves that it is indeed possible to craft *some*​ slow blocks, > and they can refer to an expert to confirm that it can be made much worse. > Of course, i remain open to feedback. > On Wednesday, February 25th, 2026 at 12:03 PM, Jameson Lopp < > jameso...@gmail.com> wrote: > > The main concern I'd have is whether or not doing so would leak more > information to the world about how to conduct such an attack on mainnet. It > may be prudent to perform such testing privately. > > On Fri, Feb 13, 2026 at 5:28 PM 'Antoine Poinsot' via Bitcoin Development > Mailing List wrote: > >> Hi everyone, >> >> Bitcoin Inquisition 29.2 was released last week with support for BIP 54 >> (Consensus Cleanup) [0]. BIP >> 54 is now active on Inquisition since block 291168. >> >> By virtue of being a bugfix soft fork rather than introducing new >> features, there is fewer avenues >> for testing on the public Signet network. Perhaps we could create a >> Signet block that is slow but >> not quite as bad as the worst case, and share it here to demonstrate it >> is now invalid on >> Inquisition? >> >> At any rate, please let us know if you find anything in testing whether >> it is on the public Signet >> network, in private ones, or however else. >> >> Best, >> Antoine Poinsot >> >> [0] https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236 >> >> -- >> 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/wJZkcSEOQD5Z8rsel8TJCSkUJiwn7YepjyOfSDHKt3P_4Fvh9MFu_oiva3G6C-Q_1CmRTCj6lqmVm6ZeZG8WbdVrCo4IZUFg3VazRdJ48AQ%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+...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CADL_X_ewFMqLuv7MVfWCZf3QhKezW9xiS19xWdROjtoT9dmU7w%40mail.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+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/273ith9pPyipCI5hjV6ETFBzFhM4xFN8ptEFK8zc5N-jxGwOBvEn5r9Bt2c9p0A-6-3Bs53gONglzo1QfI4LCIOwkJgR9PWT4iQT_Wbpllo%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/6f396784-837f-4764-b9f2-f4fe7ec1555bn%40googlegroups.com.