BIP 54 active on Bitcoin Inquisition

[Antoine Poinsot]

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

[Jameson Lopp]

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.

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

[Antoine Poinsot]

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.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_ewFMqLuv7MVfWCZf3QhKezW9xiS19xWdROjtoT9dmU7w%40mail.gmail.com.

[Antoine Poinsot]

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.

Antoine Poinsot

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/273ith9pPyipCI5hjV6ETFBzFhM4xFN8ptEFK8zc5N-jxGwOBvEn5r9Bt2c9p0A-6-3Bs53gONglzo1QfI4LCIOwkJgR9PWT4iQT_Wbpllo%3D%40protonmail.com.

[Antoine Riard]

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