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:
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.
--
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.