From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: BIP54 implementation and test vectors
Date: Sun, 26 Oct 2025 22:21:06 -0700 (PDT) [thread overview]
Message-ID: <e8d7baa0-5d96-4e41-8cb5-083742c61454n@googlegroups.com> (raw)
In-Reply-To: <V0qeILOW1CuH3NS2O8IUdQBK8i3o8LwzLNGf7xh1UO0S_Gzui1CpdP5NhdT3EtrW6NgqxJ538egeag6bVZoBX8C8E46ZYTCyPg1qBxkwCXs=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5127 bytes --]
Hi Poinsot,
Started to review a bit the code branch on inquisition, and while doing so
I was specifically
thinking about the proposed 2500 sigops limit, and how it weights on a
multi-dimensional matrix
of a full-node performace (e.g fees, CPU time, disk space, etc).
Currently, in a simple model, a DoS adversary could constitute a 1-MB (it's
pre-segwit acoutning)
transaction with 80_000 sigops from a 1-sat UTXO. A full-node to validate
that would have to SHA256
the 1MB tx 80_000 times, thus the O(n^2) "bad" complexity.
Assuming the novel per-tx 2500 sigops limit, still a simple DoS adversary
could constitute 32 * 32_150
virtual bytes tx (it's still a 1 MB block) spending from _32_ 1-sat UTXOs.
A full-node to validate that
would have to fetch the 32 UTXOs.
This is the 1 UTXO from 32 UTXOs trade-off, I would like to draw awareness
on, as fair the O(n^2)
complexity is "bad" but quid of the UTXO memory fetches if there are not in
your high-hierarchy cache
and they have to be fetched from RAM, or even worst from disk (i7 core have
RAM bigger than the current
UTXO set, not necessarily all range of RasPi).
From the viewpoint of a defending full-node, sure I can limit the number of
per-tx sigops, but if an
adversary can achieve the same DoS efficiency now that more than UTXOs have
to be fetched to validate
the same per-block total number of sigops, it's a legitimate wonder about
the efficiency limit, and
more interestingly if there wouldn't be a better value to be selected.
So it's a bit my interrogation about this 2500 proposal, if worst-case
transactions samples binding
to the 2500 limit have been crafted to maximize the number of UTXOs
fetches. One can make the hypothesis
that UTXO fetches are "free", but I don't think it's necessarily true,
while on the other hand modern ISAs
have dedicated hashing instructions.
Current BIP54 is a bit silent if full-node performance metrics like CPU
cycles, IO disk operations or
bandwidth consumptions have been weighted in to select the proposed 2500
value of the limit. This would
be a fair point to modify BIP54 to say that the new sigops limit is only
aimed to mitigate CPU DoS
and that others dimensions like memory management have not been emperically
observed to be downgraded.
Best,
Antoine
OTS hash: 975674252060994d92eecd63a924e7530623ee737e33c5646d382f0f8c04ec74
Le mardi 21 octobre 2025 à 18:17:21 UTC+1, Antoine Poinsot a écrit :
> Hi everyone,
>
> I'd like to give an update on my Consensus Cleanup work, now BIP54.
>
> I opened an implementation against Bitcoin Inquisition v29.1 at [0]. It
> contains extensive testing
> of each of the four proposed mitigations, and was used as a basis to
> generate test vectors for
> BIP54. I opened a PR against the BIPs repository to add them to BIP54 [1].
>
> The test vectors for the transaction-level sigops limit contain a wide
> variety of usage combinations
> as well as ways of running into the limit. They also include some
> historical violations as well as
> pathological transactions demonstrating the implementation details of the
> sigop accounting logic
> (which was itself borrowed from that of BIP16, which all Bitcoin
> implementations presumably already
> have).
>
> The test vectors for the new witness-stripped transaction size restriction
> similarly exercise the
> bounds of the check under various conditions (e.g. transactions
> with/without a witness). All
> historical violations were also added to the test vectors, thanks to Chris
> Stewart for digging those
> up.
>
> Because the new timestamp restrictions are tailor-made to the mainnet
> difficulty adjustment
> parameters, the test vectors for those contain a number of chains of
> mainnet headers (from genesis).
> Each test case contains a full header chain and whether it is valid
> according to BIP54. These chains
> were generated using a custom miner available in [2] and added to the
> implementation as a JSON data
> file.
>
> The test vectors for the coinbase restriction similarly include a chain of
> mainnet blocks, because
> the timelock check is context-dependent. These were generated using a
> similar miner also available
> at [2].
>
> I'm seeking feedback on these test vectors from everybody but in
> particular developers of
> alternative Bitcoin clients, as compatibility with other Bitcoin
> implementations than Bitcoin Core
> was a design goal.
>
> Best,
> Antoine Poinsot
>
> [0]: https://github.com/bitcoin-inquisition/bitcoin/pull/99
> [1]: https://github.com/bitcoin/bips/pull/2015
> [2]: https://github.com/darosior/bitcoin/commits/bip54_miner
>
--
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/e8d7baa0-5d96-4e41-8cb5-083742c61454n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6613 bytes --]
next prev parent reply other threads:[~2025-10-27 5:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 15:46 [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-10-27 5:21 ` Antoine Riard [this message]
2025-10-28 9:53 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-11-10 1:40 ` Antoine Riard
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=e8d7baa0-5d96-4e41-8cb5-083742c61454n@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