BIP 54 active on Bitcoin Inquisition
5 messages, 13 Feb to 15 Apr 2026. Started by Antoine Poinsot.
Antoine Poinsot (2), Jameson Lopp, Antoine Riard, 0xB10C
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
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 <bitcoindev@googlegroups•com> wrote:
Quoted text (32 lines)
> 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+unsubscribe@googlegroups•com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/wJZkcSEOQD5Z8rsel8TJCSkUJiwn7YepjyOfSDHKt3P_4Fvh9MFu_oiva3G6C-Q_1CmRTCj6lqmVm6ZeZG8WbdVrCo4IZUFg3VazRdJ48AQ%3D%40protonmail.com > . >
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 <jameson.lopp@gmail•com> wrote:
Quoted text (31 lines)
> 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 <bitcoindev@googlegroups•com> 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+unsubscribe@googlegroups•com](mailto:bitcoindev%2Bunsubscribe@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+unsubscribe@googlegroups•com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_ewFMqLuv7MVfWCZf3QhKezW9xiS19xWdROjtoT9dmU7w%40mail.gmail.com.
Hello,
Quoted text (1 line)
> 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...
Quoted text (1 line)
> 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 :
Quoted text (140 lines)
> 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 <https://github.com/0xB10C/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 <bitco...@googlegroups•com> 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 <bitco...@googlegroups•com> 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 > . > > >
Hi,
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.
There was yet another demo of this on April 8th and 9th. It's documented on https://delvingbitcoin.org/t/consensus-cleanup-demo-of-slow-blocks-on-signet/2367 and had quite a few participants running it and sharing their block validation times across a wide range of CPUs.
For the recent demo, I set up some P2P monitoring with a custom client that connects to all ~190 listening Signet on IPv4 and Tor. This client, for example, requested high-bandwith compact blocks from all nodes and kept track of Bitcoin protocol ping-pong RTT times. Recoding timestamps of block annoucements and the time when a peer would respond to my getblocktxn requests with blocktxn's allows to monitor validation times across the network (limited to the listening part of the network).
I've written about it in detail on https://bnoc.xyz/t/block-propagation-and-validation-duration-during-slow-to-validate-blocks-on-signet/117
I'm writing here to share a few numbers: - during normal network conditions, a median listening node on Signet takes 176ms to validate a block (25th percentile: 37ms; 75th percentile 447ms). Almost all listening nodes can validated the normal blocks in less than a second. - during the slow-to-validate event last week, it took a median listing node 19.7s to validate a block (25th percentile 8.2s; 75th percentile 32s). The 90th percentile takes close to 80s. - When looking at the mulitple, the median validation takes about 160x longer than validationg a normal block (25th percentile: 31x, 75th percentile: 793x).
Keep in mind that these numbers are for the "expensive-but-far-from-worst blocks" that Antoine chose to disclose.
Best b10c
On Wednesday, March 11th, 2026 at 11:27 AM, 'Antoine Poinsot' via Bitcoin Development Mailing List <bitco...@googlegroups•com> 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 <bitco...@googlegroups•com> 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