From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 09 Nov 2025 17:48:58 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vIH1c-0002Uk-Mm for bitcoindev@gnusha.org; Sun, 09 Nov 2025 17:48:58 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-3d1e14c1533sf5258119fac.3 for ; Sun, 09 Nov 2025 17:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762739330; x=1763344130; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=J2rWA28K4X5rJi41sUP0KTtH0p2HSoNmTS1rsqsu/OU=; b=ZSXAEk3LIxKnOrEhVQWwSd+4NVgFm8BqkLjjzrnhdhL7ZGCuCTJSy+N0L0YtaQCSr6 Umb4qSlqsJAEUSweKBQi8prBZeAtW+veDHSTdy98DV5u7yODA/e705JSk/IuPiS8fjgL xijHGPwjcIpJZihi1vePlqPCLdOWxL4UXQ2VbEAXnAvGPjXfaajC9eCab54YD6EYI2+y 5Mdcide8WvshAjQ092tUx1wK1bWbtc/5xVXc2FQzsqwWWdqcF//UcXVNcuNj+KOT7GpX JpEKggGdHZw1k0cIbb+WbiAvDfvvbrCE2pc3EVCKu90LEm6XExVPTVv3Ct1//d26Cdfu nzxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762739330; x=1763344130; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=J2rWA28K4X5rJi41sUP0KTtH0p2HSoNmTS1rsqsu/OU=; b=gTIpfK7kPhn7ARZ1B6X+zbLfYR5/jgGBwXHSfOS8ZpoT36waIcdX3nY7XPfz8afDRf 1wZC6vKcEPIHp6YsdG3HQezxKuNloSYcMn0Xnl88GVYVWjPFfLp9OkmlnaGTIxNc7t9W 9fE0k3gaLtQeOHszgRYY/P95K1KiJxn8aiyY6EKsUxQyc0qoDzyjt/NRVYhvzLYWvtLS L2FNTa2AKNXW7YqwC9yVwBd22BNKSmAKm/gTwncNCn36kzW/veDn8J/Drcl7bQ7CHLPK WmwRz1lJFvt4+lxjLhjVR49Sn8B/j9Y5Ou7ZB+KUw2wMIdMAdCCQh87XRGPhW23J6QVH V32g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762739330; x=1763344130; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=J2rWA28K4X5rJi41sUP0KTtH0p2HSoNmTS1rsqsu/OU=; b=hlmF9kRdAvbgRJbqKr7EPO+jUAkyyPX0xxctJ3R4qu0bjbdcLDWKWSs84ZNcIQKQ9p SoixtWdBKreqBZgO7LuulAa5Mcaw7avO6dy3l6Z0Z4eKW4WfOlyogl9HGnMISqGj0Z0b uUC06kmpImmGANZbOvwD0tR67L7rcoys0fYQMdiSsrAqltW8l5GloSQ+AVhtL64dkZOs 09kXn/gsw4QlhWaSVylhBUkooE9XZT5QMHMjqzqghjhvRZUkazwBEh4qt/Jdvm31o1lb Vad+h2iWzPEA6zigI5eWCZcOf9lf7RDTgCJ6JFr30cRRNuGxly/51fq1gkgCfmJ2GL/c srkw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWv0r1pODWkurJ8EZ0SqzRJuTuCHBxH+/UMkh3UAEtyRqi7oaIGWkPGauk/xZvg+oswcXDyGeidD5l8@gnusha.org X-Gm-Message-State: AOJu0YxkA6SmcyVUZXFZGtXh9C4H+wqS6o4ViRsd3MGlVH+xu6zoVoGl qbcVDmKVQvQudMFlw1sOCQnVjzoEJM46KtmyvFNzpHUFDh8Rp9QpdInx X-Google-Smtp-Source: AGHT+IG8Dz+CT/bFOjnxaBkMQ6FDVSckHiRFqGCHCxFW4Ws4PjDg/dDo5Ogv4R2VOuSLvR+X//8AUA== X-Received: by 2002:a05:6870:8136:b0:35e:59ce:6c26 with SMTP id 586e51a60fabf-3e7c2860585mr4798238fac.40.1762739330049; Sun, 09 Nov 2025 17:48:50 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bttmfzIU6/LsTLWNMAwN+r4eTS0Z3nMqkl2pZpHhQ/wA==" Received: by 2002:a05:6871:bd11:b0:3d3:6b50:4f3a with SMTP id 586e51a60fabf-3e2f1df6ddels1828165fac.0.-pod-prod-07-us; Sun, 09 Nov 2025 17:48:44 -0800 (PST) X-Received: by 2002:a05:6808:3a0e:b0:44d:b83a:cf4e with SMTP id 5614622812f47-4502a35f458mr3512779b6e.35.1762739324683; Sun, 09 Nov 2025 17:48:44 -0800 (PST) Received: by 2002:a05:690c:55c3:20b0:786:8d90:70d8 with SMTP id 00721157ae682-786a513df0ams7b3; Sun, 9 Nov 2025 17:40:59 -0800 (PST) X-Received: by 2002:a05:690c:9b08:b0:783:71ee:8977 with SMTP id 00721157ae682-787d535017emr64582567b3.11.1762738858957; Sun, 09 Nov 2025 17:40:58 -0800 (PST) Date: Sun, 9 Nov 2025 17:40:58 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <5fe13896-913c-4b16-8507-69809b369612n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Re: BIP54 implementation and test vectors MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_876996_404664032.1762738858460" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_876996_404664032.1762738858460 Content-Type: multipart/alternative; boundary="----=_Part_876997_1519883179.1762738858460" ------=_Part_876997_1519883179.1762738858460 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot, Thanks for the precision. Yes my wonder is more if you put yourself in the= =20 shoes of an attacker, and you have to calculate your cost for an attack, what is the most=20 interesting between playing on the number of prevout lookups and maximizing the quadratic hashing. I do=20 believe the proposed 2500 sigops limit is slashing the quadratic hashing worst-case concern, while at= =20 the same time not providing an advantage to the attacker on the prevout lookup cost. Say differently, I= =20 believe we should ensure that any introduced DoS limit in the goal to reduce worst-case for a DoS vector= =20 A do not downgrade the worst-case for another DoS vector B.=20 Previously, as the way the novel limit was proposed in abstracto, I had a= =20 concern with given that if you take for example bitcoin core multiple input checks where made=20 (first all scripts flags and then for consensus mandatory script flags) [0], a DoS attacker could have= =20 deliberately make the script failed on a policy flag and then make it hard fails on the novel=20 2500 limit, _at a cheaper price_ (less CHECKMULTISIG bytes to pack in the tx). I don't think it's a= =20 concern anymore as after [1] and others, there is no double validation anymore and=20 `CheckSigOpsBIP54` has been implemented with the other policy check limits. Of course the number of CHECKMULTISIG bytes to pack is only a concern for= =20 an attacker in the situation where satoshis have to be provided to pass the `min_relay_feerate` policy= =20 rule, but it's a realistic limit one has to reason when you're considering the cost of network-wide=20 DoS. Somehow, you're maximizing the higher DoS cost per byte per satoshi you might have to commit in a=20 single tx. Disagree with you on the prevout lookup cost exploitation, as I think there= =20 is at least variant to attempt to slash the cost for an attacker for some categories of DoS. But= =20 yes seen the calculations for various DoS blocks, and that can be discussed elsewhere. Anyway, finished a first round of review of the BIP54 test cases, probably= =20 few vectors missings like for the 64 byte and Taproot transaction with empty or full annex. I'll= =20 do more review rounds of it, in parallel of the bitcoin-inquisition branch. Best, Antoine OTS hash: 223aeb5ea932ada762b2d4181b8430b7cbf937579eccd467769c0284276e9595 [0] https://github.com/bitcoin/bitcoin/pull/31097 [1] https://github.com/bitcoin/bitcoin/pull/32473 Le mardi 28 octobre 2025 =C3=A0 10:06:28 UTC, Antoine Poinsot a =C3=A9crit = : > Hi Riard, > > Thanks for the feedback. I understand your point as asking about other=20 > costs besides quadratic > hashing, and how the BIP54 "potentially executed" sigop limit relates to= =20 > those. > > There are indeed several other expensive operations when validating a=20 > block: ECDSA signature > verifications, FindAndDelete's vector modifications, and prevout lookups.= =20 > This last one is related > to the recently discussed limit on scriptPubKey sizes [0], as they presen= t=20 > a constant factor > increase in the lookup cost that is not bounded by the size of the block= =20 > being validated. > > In any case the cost of these other expensive operations is completely=20 > dwarfed by quadratic hashing. The > example you give is unfortunately far from the worst case. I added you to= =20 > the semi-private Delving > thread [1] which contains the detail of the calculations for various DoS= =20 > blocks. Feel free also to > reach out to me in private, if you prefer email to Delving. > > Furthermore, exploiting the prevout lookup cost is highly uneconomical to= =20 > a miner. It requires over > a hundred preparation blocks in order to create a single block that would= =20 > take a couple dozens of > seconds to validate on a modern machine. By comparison, without the BIP54= =20 > sigops limit this same > effect can be achieved with 2 orders of magnitude less preparation blocks= ,=20 > making the attack viable > for a revenue-maximizing miner. Without the BIP54 sigops limit, over a=20 > hundred preparation blocks > also gets you a block that takes over 10 minutes to validate on a modern= =20 > machine. > > Finally, besides having diminishing returns these mitigations would also= =20 > have a higher confiscatory > surface [2]. The BIP54 mitigation was chosen because it pinpoints exactly= =20 > the harmful behaviour we > want to prevent, with only a minimal impact on potentially legitimate=20 > usage [3], while making > attacks of miners on their competition uneconomical as well as making the= =20 > very worst case largely > uninteresting to an externally-motivated attacker. > > Best, > Antoine > > [0]:=20 > https://gnusha.org/pi/bitcoindev/OAoV-Uev9IosyhtUCyeIhclsVq-xUBZgGFROALaC= KZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrKjChc=3D@prot= onmail.com/ > [1]: https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711 > [2]: See for instance regarding the scriptPubKey size limit=20 > https://gnusha.org/pi/bitcoindev/CAAS2fgQEdVVcb=3DDfP7XoRxfXfq1unKBD...@m= ail.gmail.com/=20 > > [3]: If a miner wants to sweep more than 2500 P2PK utxos in a single=20 > non-standard transaction, they > now need to use more than one transaction but they can still do it. > > On Monday, October 27th, 2025 at 1:36 AM, Antoine Riard < > antoin...@gmail.com> wrote: > > > Hi Poinsot, > >=20 > > Started to review a bit the code branch on inquisition, and while doing= =20 > so I was specifically > > thinking about the proposed 2500 sigops limit, and how it weights on a= =20 > multi-dimensional matrix > > of a full-node performace (e.g fees, CPU time, disk space, etc). > >=20 > > Currently, in a simple model, a DoS adversary could constitute a 1-MB= =20 > (it's pre-segwit acoutning) > > transaction with 80_000 sigops from a 1-sat UTXO. A full-node to=20 > validate that would have to SHA256 > > the 1MB tx 80_000 times, thus the O(n^2) "bad" complexity. > >=20 > > Assuming the novel per-tx 2500 sigops limit, still a simple DoS=20 > adversary could constitute 32 * 32_150 > > virtual bytes tx (it's still a 1 MB block) spending from _32_ 1-sat=20 > UTXOs. A full-node to validate that > > would have to fetch the 32 UTXOs. > >=20 > > This is the 1 UTXO from 32 UTXOs trade-off, I would like to draw=20 > awareness on, as fair the O(n^2) > > complexity is "bad" but quid of the UTXO memory fetches if there are no= t=20 > in your high-hierarchy cache > > and they have to be fetched from RAM, or even worst from disk (i7 core= =20 > have RAM bigger than the current > > UTXO set, not necessarily all range of RasPi). > >=20 > > From the viewpoint of a defending full-node, sure I can limit the numbe= r=20 > of per-tx sigops, but if an > > adversary can achieve the same DoS efficiency now that more than UTXOs= =20 > have to be fetched to validate > > the same per-block total number of sigops, it's a legitimate wonder=20 > about the efficiency limit, and > > more interestingly if there wouldn't be a better value to be selected. > >=20 > > So it's a bit my interrogation about this 2500 proposal, if worst-case= =20 > transactions samples binding > > to the 2500 limit have been crafted to maximize the number of UTXOs=20 > fetches. One can make the hypothesis > > that UTXO fetches are "free", but I don't think it's necessarily true,= =20 > while on the other hand modern ISAs > > have dedicated hashing instructions. > >=20 > > Current BIP54 is a bit silent if full-node performance metrics like CPU= =20 > cycles, IO disk operations or > > bandwidth consumptions have been weighted in to select the proposed 250= 0=20 > value of the limit. This would > > be a fair point to modify BIP54 to say that the new sigops limit is onl= y=20 > aimed to mitigate CPU DoS > > and that others dimensions like memory management have not been=20 > emperically observed to be downgraded. > >=20 > > Best, > > Antoine > > OTS hash:=20 > 975674252060994d92eecd63a924e7530623ee737e33c5646d382f0f8c04ec74 > >=20 > >=20 > > Le mardi 21 octobre 2025 =C3=A0 18:17:21 UTC+1, Antoine Poinsot a =C3= =A9crit : > >=20 > > > Hi everyone, > > >=20 > > > I'd like to give an update on my Consensus Cleanup work, now BIP54. > > >=20 > > > I opened an implementation against Bitcoin Inquisition v29.1 at [0].= =20 > It contains extensive testing > > > of each of the four proposed mitigations, and was used as a basis to= =20 > generate test vectors for > > > BIP54. I opened a PR against the BIPs repository to add them to BIP54= =20 > [1]. > > >=20 > > > The test vectors for the transaction-level sigops limit contain a wid= e=20 > variety of usage combinations > > > as well as ways of running into the limit. They also include some=20 > historical violations as well as > > > pathological transactions demonstrating the implementation details of= =20 > the sigop accounting logic > > > (which was itself borrowed from that of BIP16, which all Bitcoin=20 > implementations presumably already > > > have). > > >=20 > > > The test vectors for the new witness-stripped transaction size=20 > restriction similarly exercise the > > > bounds of the check under various conditions (e.g. transactions=20 > with/without a witness). All > > > historical violations were also added to the test vectors, thanks to= =20 > Chris Stewart for digging those > > > up. > > >=20 > > > Because the new timestamp restrictions are tailor-made to the mainnet= =20 > difficulty adjustment > > > parameters, the test vectors for those contain a number of chains of= =20 > mainnet headers (from genesis). > > > Each test case contains a full header chain and whether it is valid= =20 > according to BIP54. These chains > > > were generated using a custom miner available in [2] and added to the= =20 > implementation as a JSON data > > > file. > > >=20 > > > The test vectors for the coinbase restriction similarly include a=20 > chain of mainnet blocks, because > > > the timelock check is context-dependent. These were generated using a= =20 > similar miner also available > > > at [2]. > > >=20 > > > I'm seeking feedback on these test vectors from everybody but in=20 > particular developers of > > > alternative Bitcoin clients, as compatibility with other Bitcoin=20 > implementations than Bitcoin Core > > > was a design goal. > > >=20 > > > Best, > > > Antoine Poinsot > > >=20 > > > [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 > >=20 > > -- > > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/e8d7baa0-5d96-4e41-8cb5-0837= 42c61454n%40googlegroups.com > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 5fe13896-913c-4b16-8507-69809b369612n%40googlegroups.com. ------=_Part_876997_1519883179.1762738858460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Poinsot,

Thanks for the precision. Yes my wonder is more if y= ou put yourself in the shoes of an attacker,
and you have to calculate= your cost for an attack, what is the most interesting between playing onthe number of prevout lookups and maximizing the quadratic hashing. I d= o believe the proposed 2500
sigops limit is slashing the quadratic has= hing worst-case concern, while at the same time not providing
an advan= tage to the attacker on the prevout lookup cost. Say differently, I believe= we should ensure that
any introduced DoS limit in the goal to reduce = worst-case for a DoS vector A do not downgrade the worst-case
for anot= her DoS vector B.

Previously, as the way the novel limit was pr= oposed in abstracto, I had a concern with given that
if you take for e= xample bitcoin core multiple input checks where made (first all scripts fla= gs and
then for consensus mandatory script flags) [0], a DoS attacker = could have deliberately make the
script failed on a policy flag and th= en make it hard fails on the novel 2500 limit, _at a cheaper
price_ (l= ess CHECKMULTISIG bytes to pack in the tx). I don't think it's a concern an= ymore as after
[1] and others, there is no double validation anymore a= nd `CheckSigOpsBIP54` has been implemented
with the other policy check= limits.

Of course the number of CHECKMULTISIG bytes to pack is = only a concern for an attacker in the situation
where satoshis have to= be provided to pass the `min_relay_feerate` policy rule, but it's a realis= tic
limit one has to reason when you're considering the cost of networ= k-wide DoS. Somehow, you're maximizing
the higher DoS cost per byte pe= r satoshi you might have to commit in a single tx.

Disagree with= you on the prevout lookup cost exploitation, as I think there is at least = variant to
attempt to slash the cost for an attacker for some categori= es of DoS. But yes seen the calculations
for various DoS blocks, and t= hat can be discussed elsewhere.

Anyway, finished a first round o= f review of the BIP54 test cases, probably few vectors missings
like f= or the 64 byte and Taproot transaction with empty or full annex. I'll do mo= re review rounds
of it, in parallel of the bitcoin-inquisition branch.=

Best,
Antoine
OTS hash: 223aeb5ea932ada762b2d4181b843= 0b7cbf937579eccd467769c0284276e9595

[0] https://github.com/bitco= in/bitcoin/pull/31097
[1] https://github.com/bitcoin/bitcoin/pull/3247= 3

Le mardi 28 octobre 2025 =C3=A0 10:06:28 UTC, Antoine Poinsot a =C3=A9c= rit=C2=A0:
Hi= Riard,

Thanks for the feedback. I understand your point as asking about other = costs besides quadratic
hashing, and how the BIP54 "potentially executed" sigop limit= relates to those.

There are indeed several other expensive operations when validating a b= lock: ECDSA signature
verifications, FindAndDelete's vector modifications, and prevout lo= okups. This last one is related
to the recently discussed limit on scriptPubKey sizes [0], as they pres= ent a constant factor
increase in the lookup cost that is not bounded by the size of the bloc= k being validated.

In any case the cost of these other expensive operations is completely = dwarfed by quadratic hashing. The
example you give is unfortunately far from the worst case. I added you = to the semi-private Delving
thread [1] which contains the detail of the calculations for various Do= S blocks. Feel free also to
reach out to me in private, if you prefer email to Delving.

Furthermore, exploiting the prevout lookup cost is highly uneconomical = to a miner. It requires over
a hundred preparation blocks in order to create a single block that wou= ld take a couple dozens of
seconds to validate on a modern machine. By comparison, without the BIP= 54 sigops limit this same
effect can be achieved with 2 orders of magnitude less preparation bloc= ks, making the attack viable
for a revenue-maximizing miner. Without the BIP54 sigops limit, over a = hundred preparation blocks
also gets you a block that takes over 10 minutes to validate on a moder= n machine.

Finally, besides having diminishing returns these mitigations would als= o have a higher confiscatory
surface [2]. The BIP54 mitigation was chosen because it pinpoints exact= ly the harmful behaviour we
want to prevent, with only a minimal impact on potentially legitimate u= sage [3], while making
attacks of miners on their competition uneconomical as well as making t= he very worst case largely
uninteresting to an externally-motivated attacker.

Best,
Antoine

[0]: https://gnusha.org/pi/bitcoindev/OAoV-Uev9IosyhtUCyeIhclsVq-xUBZgGFROAL= aCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrKjChc=3D@pr= otonmail.com/
[1]: https://delvingbitcoin.org/t= /worst-block-validation-time-inquiry/711
[2]: See for instance regarding the scriptPubKey size limit https://gnusha.org/pi/bitcoindev/CAAS2fgQEdVVcb=3DDfP7X= oRxfXfq1unKBD...@mail.gmail.com/
[3]: If a miner wants to sweep more than 2500 P2PK utxos in a single no= n-standard transaction, they
now need to use more than one transaction but they can still do it= .

On Monday, October 27th, 2025 at 1:36 AM, Antoine Riard <antoin...@gmail.com> wrote:

> Hi Poinsot,
>=20
> 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).
>=20
> 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 v= alidate that would have to SHA256
> the 1MB tx 80_000 times, thus the O(n^2) "bad" complexit= y.
>=20
> Assuming the novel per-tx 2500 sigops limit, still a simple DoS ad= versary 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.
>=20
> This is the 1 UTXO from 32 UTXOs trade-off, I would like to draw a= wareness 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).
>=20
> 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 U= TXOs have to be fetched to validate
> the same per-block total number of sigops, it's a legitimate w= onder about the efficiency limit, and
> more interestingly if there wouldn't be a better value to be s= elected.
>=20
> So it's a bit my interrogation about this 2500 proposal, if wo= rst-case transactions samples binding
> to the 2500 limit have been crafted to maximize the number of UTXO= s fetches. One can make the hypothesis
> that UTXO fetches are "free", but I don't think it&#= 39;s necessarily true, while on the other hand modern ISAs
> have dedicated hashing instructions.
>=20
> Current BIP54 is a bit silent if full-node performance metrics lik= e CPU cycles, IO disk operations or
> bandwidth consumptions have been weighted in to select the propose= d 2500 value of the limit. This would
> be a fair point to modify BIP54 to say that the new sigops limit i= s only aimed to mitigate CPU DoS
> and that others dimensions like memory management have not been em= perically observed to be downgraded.
>=20
> Best,
> Antoine
> OTS hash: 975674252060994d92eecd63a924e7530623ee737e33c5646d382f0f= 8c04ec74
>=20
>=20
> Le mardi 21 octobre 2025 =C3=A0 18:17:21 UTC+1, Antoine Poinsot a = =C3=A9crit :
>=20
> > Hi everyone,
> >=20
> > I'd like to give an update on my Consensus Cleanup work, = now BIP54.
> >=20
> > 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 b= asis to generate test vectors for
> > BIP54. I opened a PR against the BIPs repository to add them = to BIP54 [1].
> >=20
> > The test vectors for the transaction-level sigops limit conta= in 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 de= tails of the sigop accounting logic
> > (which was itself borrowed from that of BIP16, which all Bitc= oin implementations presumably already
> > have).
> >=20
> > The test vectors for the new witness-stripped transaction siz= e restriction similarly exercise the
> > bounds of the check under various conditions (e.g. transactio= ns with/without a witness). All
> > historical violations were also added to the test vectors, th= anks to Chris Stewart for digging those
> > up.
> >=20
> > Because the new timestamp restrictions are tailor-made to the= mainnet difficulty adjustment
> > parameters, the test vectors for those contain a number of ch= ains 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 adde= d to the implementation as a JSON data
> > file.
> >=20
> > The test vectors for the coinbase restriction similarly inclu= de a chain of mainnet blocks, because
> > the timelock check is context-dependent. These were generated= using a similar miner also available
> > at [2].
> >=20
> > I'm seeking feedback on these test vectors from everybody= but in particular developers of
> > alternative Bitcoin clients, as compatibility with other Bitc= oin implementations than Bitcoin Core
> > was a design goal.
> >=20
> > Best,
> > Antoine Poinsot
> >=20
> > [0]: https://github.com/bitcoin-inquisition/bitcoin= /pull/99
> > [1]: https://github.com/bitcoin/bips/pull/2015
> > [2]: https://github.com/darosior/bitcoin/commit= s/bip54_miner
>=20
> --
> 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/e8d7baa0-5d96-4e41-8cb5-083742c6145= 4n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/5fe13896-913c-4b16-8507-69809b369612n%40googlegroups.com.
------=_Part_876997_1519883179.1762738858460-- ------=_Part_876996_404664032.1762738858460--