From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP 54 active on Bitcoin Inquisition
Date: Mon, 30 Mar 2026 20:09:55 -0700 (PDT) [thread overview]
Message-ID: <6f396784-837f-4764-b9f2-f4fe7ec1555bn@googlegroups.com> (raw)
In-Reply-To: <Gehatc25PHdVzbYtnOGCDUsV7-ibRuP7gls32r4gekZGGjZI0o22lUvMhK27lv4B7_Cgb9MZA4-KmkI5wM_GL9GHWPaGA4sPNR5Mn7Kaz2c=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 9557 bytes --]
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 <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
> .
>
>
>
--
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.
[-- Attachment #1.2: Type: text/html, Size: 16658 bytes --]
prev parent reply other threads:[~2026-03-31 9:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 22:27 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-02-25 16:49 ` Jameson Lopp
2026-03-11 15:02 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
[not found] ` <Gehatc25PHdVzbYtnOGCDUsV7-ibRuP7gls32r4gekZGGjZI0o22lUvMhK27lv4B7_Cgb9MZA4-KmkI5wM_GL9GHWPaGA4sPNR5Mn7Kaz2c=@protonmail.com>
2026-03-31 3:09 ` Antoine Riard [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=6f396784-837f-4764-b9f2-f4fe7ec1555bn@googlegroups.com \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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