From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 26 Oct 2025 22:36:22 -0700 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 1vDFu1-0002PC-Ag for bitcoindev@gnusha.org; Sun, 26 Oct 2025 22:36:22 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-3c98354c16esf1109125fac.2 for ; Sun, 26 Oct 2025 22:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761543375; x=1762148175; 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=2dWOF0m3IumSafSq/q5woqVyQai7sDdSP0njdMaR+/A=; b=QMbBaLTjvMmVc2gxLZdNDQame+Jua0a2RntMvyFLOq1xt3ADZgKGm8qUqa3JtYEbzc cEOd+11qfkmWUXEFZ5p2q2Rh3MI1fxBO5i9GRcWwcMKM18fcqRaPy2mwV1gUB/Mx8vaV YGUhWEulo81BcyCizIfSTcQGd6Px+gV48JILMuq1sIs0WmVfDWOX3SJndlDxeL6Pk1RC RYx37yWwZ63xmmgATLv+pN+Eff1yE4SkIp87fG4utpvD5SjEcuSn4QF9imAK0Yj2oVIc Tfr2p96MP9bRrsjaUoE8ZixBVJQSZah0cDWwzNlMta+WBReBkD6wwLavuK6EIt8fYVzG zfGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761543375; x=1762148175; 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=2dWOF0m3IumSafSq/q5woqVyQai7sDdSP0njdMaR+/A=; b=E6w/d3DZtlYH92/GgxZT5fV/7fzofsYSoxKuNAbfviLF9z1qnaj7otJ8traMyV7J0u jHsozYEZRteEG0//lwUYxCcHnmBjNDof6eAQZojzXS0VBcy+ac7jv3T607GUpIPjULYx ae8nmZNnv9ji9VMoq9sAhST0iJiTZHtNLXbkizKWunmoLhG629Bl6gfinga3FkWR29Rc OyqriVKHo1ySrQryQLoxugObRrkNUS1FCEg+UEIJJSmrjcT07xU60sslrsFxDk5NWNnc 6rZlLOeKtbTr+tzEPwcf0ZOYglrXghARL8BuCyl6oXov5XX1X4bmmY/97NgyE7fFQJ2r 8Njg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761543375; x=1762148175; 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=2dWOF0m3IumSafSq/q5woqVyQai7sDdSP0njdMaR+/A=; b=wHGjIPgJGtecZ3O3fnzTHdz4HWl/yYhNDiGBKqTGrc7JTXUXcGcJ9FX5XZV3d010lC WnucZRyvWdhoNTna2YwzqGbKbq+CfD6sbU6fy5MAt2dh/Ge/u1f2DtEN+dkmlCK45uKI nhk2GZPqydJz7lQvRP1W7XuJYH8aD3uZdaNHsHOyQorZ5uLwAfUB0v3G7rqtPGWxbt0h Xqbzupi6a4cSqe8lJTpZHLTuzdLVX1Yd5RGapCVGjsSiyOPYp6UauhYjvMgAA8Rsgq8h bSSra/7rInVjC4z1dnRBFKYQ4ZLEAlqrOh9ouFpETQSdeqt7v27+t0S/esO7lmDuJ0dt GwCQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUTVt/GlaxHu9aQ4wRIk2RQL/9ZtjPreHBmqSUoK7zt4L6LHRuvKSjqqkXKQMMl/GIxfNzQfw7k1mKb@gnusha.org X-Gm-Message-State: AOJu0Yy6Ga1X337zeLE3yQaQD0anj8/PNBJlJemoPimC3Yuj7kiy5btQ 51tSG4dbAwPa6BZO8rtZ3XhFxBsbWnxglB6ClW2JQ3dh722fK11U8XZX X-Google-Smtp-Source: AGHT+IHMgH1ANL6awRaOoYpOv+94f5yEXq86aL2SM7MXmH12HHCN9lorQOVUsHpud1pIZaW0D9mVcg== X-Received: by 2002:a05:6870:6b9a:b0:3d2:a262:3d3b with SMTP id 586e51a60fabf-3d2a2624403mr2379256fac.16.1761543374829; Sun, 26 Oct 2025 22:36:14 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YsNCwXcCMAu2WHF3YM07OGLg7yj/u/Znr2tFIhTjymUw==" Received: by 2002:a05:6870:26e:b0:383:97ca:d48c with SMTP id 586e51a60fabf-3cdc648d937ls1302079fac.0.-pod-prod-04-us; Sun, 26 Oct 2025 22:36:09 -0700 (PDT) X-Received: by 2002:a05:6808:14c8:b0:438:425e:fdbb with SMTP id 5614622812f47-443a2e5348bmr16123588b6e.26.1761543369257; Sun, 26 Oct 2025 22:36:09 -0700 (PDT) Received: by 2002:a05:690c:9513:b0:780:f7eb:fdf with SMTP id 00721157ae682-785db0a4e46ms7b3; Sun, 26 Oct 2025 22:21:07 -0700 (PDT) X-Received: by 2002:a05:690e:1c19:b0:63e:3352:4eff with SMTP id 956f58d0204a3-63e33525038mr19792933d50.20.1761542466575; Sun, 26 Oct 2025 22:21:06 -0700 (PDT) Date: Sun, 26 Oct 2025 22:21:06 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: BIP54 implementation and test vectors MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_566704_1657402968.1761542466310" 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_566704_1657402968.1761542466310 Content-Type: multipart/alternative; boundary="----=_Part_566705_252431969.1761542466310" ------=_Part_566705_252431969.1761542466310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Hi Poinsot, Started to review a bit the code branch on inquisition, and while doing so= =20 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). Currently, in a simple model, a DoS adversary could constitute a 1-MB (it's= =20 pre-segwit acoutning) transaction with 80_000 sigops from a 1-sat UTXO. A full-node to validate= =20 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= =20 could constitute 32 * 32_150 virtual bytes tx (it's still a 1 MB block) spending from _32_ 1-sat UTXOs.= =20 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= =20 on, as fair the O(n^2) complexity is "bad" but quid of the UTXO memory fetches if there are not in= =20 your high-hierarchy cache and they have to be fetched from RAM, or even worst from disk (i7 core have= =20 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= =20 per-tx sigops, but if an adversary can achieve the same DoS efficiency now that more than UTXOs have= =20 to be fetched to validate the same per-block total number of sigops, it's a legitimate wonder about= =20 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. 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 2500=20 value of the limit. This would be a fair point to modify BIP54 to say that the new sigops limit is only=20 aimed to mitigate CPU DoS and that others dimensions like memory management have not been emperically= =20 observed to be downgraded. Best, Antoine OTS hash: 975674252060994d92eecd63a924e7530623ee737e33c5646d382f0f8c04ec74= =20 Le mardi 21 octobre 2025 =C3=A0 18:17:21 UTC+1, Antoine Poinsot a =C3=A9cri= t : > 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= =20 > 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 [1]= . > > The test vectors for the transaction-level sigops limit contain a wide=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 the= =20 > sigop accounting logic > (which was itself borrowed from that of BIP16, which all Bitcoin=20 > implementations presumably already > have). > > The test vectors for the new witness-stripped transaction size restrictio= n=20 > 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 Chri= s=20 > Stewart for digging those > up. > > 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. > > The test vectors for the coinbase restriction similarly include a chain o= f=20 > mainnet blocks, because > the timelock check is context-dependent. These were generated using a=20 > similar miner also available > at [2]. > > 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. > > 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 > --=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/= e8d7baa0-5d96-4e41-8cb5-083742c61454n%40googlegroups.com. ------=_Part_566705_252431969.1761542466310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Poinsot,

Started to review a bit the code branch on inquis= ition, and while doing so I was specifically
thinking about the propos= ed 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 U= TXO. A full-node to validate that would have to SHA256
the 1MB tx 80_0= 00 times, thus the O(n^2) "bad" complexity.

Assuming the novel p= er-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 U= TXOs.

This is the 1 UTXO from 32 UTXOs trade-off, I would like t= o draw awareness on, as fair the O(n^2)
complexity is "bad" but quid o= f 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 ha= ve 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 validat= e
the same per-block total number of sigops, it's a legitimate wonder = about the efficiency limit, and
more interestingly if there wouldn't b= e 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
hav= e 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 o= thers dimensions like memory management have not been emperically observed = to be downgraded.

Best,
Antoine
OTS hash: 975674252060= 994d92eecd63a924e7530623ee737e33c5646d382f0f8c04ec74=C2=A0


<= div class=3D"gmail_quote">
Le mardi 2= 1 octobre 2025 =C3=A0 18:17:21 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:
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 ge= nerate 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 histo= rical violations as well as
pathological transactions demonstrating the implementation details of t= he sigop accounting logic
(which was itself borrowed from that of BIP16, which all Bitcoin implem= entations presumably already
have).

The test vectors for the new witness-stripped transaction size restrict= ion similarly exercise the
bounds of the check under various conditions (e.g. transactions with/wi= thout a witness). All
historical violations were also added to the test vectors, thanks to Ch= ris Stewart for digging those
up.

Because the new timestamp restrictions are tailor-made to the mainnet d= ifficulty adjustment
parameters, the test vectors for those contain a number of chains of ma= innet headers (from genesis).
Each test case contains a full header chain and whether it is valid acc= ording to BIP54. These chains
were generated using a custom miner available in [2] and added to the i= mplementation 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 s= imilar miner also available
at [2].

I'm seeking feedback on these test vectors from everybody but in pa= rticular developers of
alternative Bitcoin clients, as compatibility with other Bitcoin implem= entations 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_mine= r

--
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/e8d7baa0-5d96-4e41-8cb5-083742c61454n%40googlegroups.com.
------=_Part_566705_252431969.1761542466310-- ------=_Part_566704_1657402968.1761542466310--