From: b10c <0xb10c@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP 54 active on Bitcoin Inquisition
Date: Wed, 15 Apr 2026 09:30:49 -0700 (PDT) [thread overview]
Message-ID: <8bc588f8-38fd-4ebc-a02d-ae750764bd0cn@googlegroups.com> (raw)
In-Reply-To: <Gehatc25PHdVzbYtnOGCDUsV7-ibRuP7gls32r4gekZGGjZI0o22lUvMhK27lv4B7_Cgb9MZA4-KmkI5wM_GL9GHWPaGA4sPNR5Mn7Kaz2c=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6342 bytes --]
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
--
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/8bc588f8-38fd-4ebc-a02d-ae750764bd0cn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9718 bytes --]
prev parent reply other threads:[~2026-04-15 16:50 UTC|newest]
Thread overview: 5+ 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
2026-04-15 16:30 ` b10c [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=8bc588f8-38fd-4ebc-a02d-ae750764bd0cn@googlegroups.com \
--to=0xb10c@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