From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Oct 2025 03:06:36 -0700 Received: from mail-ot1-f60.google.com ([209.85.210.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vDgb5-0006qD-BM for bitcoindev@gnusha.org; Tue, 28 Oct 2025 03:06:35 -0700 Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-7c52a4599absf2171523a34.1 for ; Tue, 28 Oct 2025 03:06:34 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761645988; cv=pass; d=google.com; s=arc-20240605; b=N6ajaqz0p/xSdET4RxrJsGusCIJqetgPinudZH6EkJc0nRPS5a4ntS4/1A7j6cc/AW /t14XmhyOZgLo2o/nPPHuWQNCwW09lzs3WiZ/mRujJhJJjmRS4QSq58M7clAbKrqFhAB I4YZUSlFp4hbeN9US8+IdvwM37i6j+dzjouoDAlFkmYNEnakanL45SkbKoT21awkW7+I l43P6l/Ju6HK5DWpKia8zmjG8HhHEr9lB1x1ktCL6YlKBhYlk372HA5zT3gXDQbMlTUE HTT8xYvyYnEUOdzkxyIC1yiyE6VFM2zPMj+ihiim6UaDfX6dY+bgMnBM2lzjqb3+skRw bRuA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=5UhtRp7CJXbJo+135k6s7A+SgKYqLVZJc2/7Zs/fQ8A=; fh=FJV3OSQ1GQiIQoS+gBBETwBjBsB6x8pzDCdAClpX/Kk=; b=FTuY9LjQyCEfIDzyspDbFl7O1J8GpxMXwU2VVFGgqODTl6WNS1rxcV9e0yQfsQ4HQ/ vcbBqUuXq92/m9Dark+JgUTM7PyKWN15WjO0H8OJfWmKaHCn7x643hXU9Aq+x+9npRE9 4iGJjmkplKK1ThDbU17AnTqufGj3Gzn5OX5cqwmQf3LPqCMoI0lL+F+LM/dj5AywtexI FAgKtDtK6Ib374vUkl9vEoU85WS1KF0sM/+O4sqsSYICaXeTbOTy4C3dRFM6a888Hqdu ZXLb/8Y20csUEYeHHrd7kiFd0VcYWzYGEWyjBw5fdyKc+Kyi5b4RRTNbVQQWzd7M42bc vUfA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=N8w+YI7+; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.17 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761645988; x=1762250788; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=5UhtRp7CJXbJo+135k6s7A+SgKYqLVZJc2/7Zs/fQ8A=; b=PCDm0NdhHVFZsXpui1xjh5jdEQPVqxdSVuYQjQw4eEat5cjWaDf5vpjba6zhw2QrmC jj48EE/D8yXcwPy8Z1V7VK0GJWbZn/IFMQtB3IcivVuGmhgS4CVguYiQFqpy6hnWn2hZ YOwkMlNk0Ou8QJJZNUgoTGDWC8t/cQhNxerqMEoN5V8HwQfrt1GoyfwEmnF8oEHAY7iA BpU7a6inamp9TjpYwXXc7JQDEJHez8ugX53V37NdUbALyXCvD1erTxod4T/ZR9szGcx2 Pm0fS5yStXePih1WvsJ+0ui1wNE39XrArfwF3EmUvf34t7LpUqMWcTbGlznn95F5BwXf Eurw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761645988; x=1762250788; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5UhtRp7CJXbJo+135k6s7A+SgKYqLVZJc2/7Zs/fQ8A=; b=ATraKXPIAU+KijwcX9whQbiyMm00HWNmHo78ht8Flu3vvuuBF2Ka5wnK0lZ1xKCNZj 2pv+sN0uKjJK5Pr5MZAOcu+C4Q0TdmEm21UTHVlNkJSsSe3jpJoMhQTGvI8f94jqHY8Q +WYxRpYar4rsL+42BqinApUBXOVQwiNGUzPbbt0KugQcZelGzUQDAZhwhy4bqdeRU4S/ xIVdvcZN6RTW46IjUnosKM97cii1kP6E4/PH1SB5BZFCOd5sSWhazV8jjj07zlZn2leb VNWVobuyU2/if6SRXmw+j05ks6g4GSZ7VeL44ygKiLWrEsEoP8HZFyYDlOXLl+USHvX5 8K6g== X-Forwarded-Encrypted: i=2; AJvYcCVsOPJofi9tOc22L4uCAJKmWz9/5HQ3dAXP7xoALzVRbzPt9xGZNk3cSG8rN9ynUCjh9TLBfn6zApMf@gnusha.org X-Gm-Message-State: AOJu0YxfdxFOnXaTP/yC+A+mF/C+ZVP8QKlnrxlhNQRMWtQQHyfwE4Q9 PQGO64r8aO4Vceih0xRkXA/EOwWTiS3hLa9donSkg/XrOiyeFFKIfNGG X-Google-Smtp-Source: AGHT+IEON/rnFB0EHpfg/i14Ho34eTr9Mvfg4/WmJqVn1Hv03r1C6YIb8FVgZukmY+aNDvouGmKL7Q== X-Received: by 2002:a05:6808:80c4:b0:44d:b760:f1bf with SMTP id 5614622812f47-44f6ba395e7mr1160802b6e.30.1761645988479; Tue, 28 Oct 2025 03:06:28 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Y8ogeOjTYzu4Zb0r7UM65Fw+3iLoP3NnQlH901/YUaAg==" Received: by 2002:a05:6871:290e:10b0:368:1447:4438 with SMTP id 586e51a60fabf-3cdc675ef3cls1557727fac.1.-pod-prod-06-us; Tue, 28 Oct 2025 03:06:24 -0700 (PDT) X-Received: by 2002:a05:6808:2201:b0:44d:a6a8:1b54 with SMTP id 5614622812f47-44f6bb46beamr1256610b6e.56.1761645984445; Tue, 28 Oct 2025 03:06:24 -0700 (PDT) Received: by 2002:a05:620a:4d13:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8a798257ca8ms85a; Tue, 28 Oct 2025 02:53:09 -0700 (PDT) X-Received: by 2002:a05:620a:190e:b0:8a0:fb41:7f35 with SMTP id af79cd13be357-8a6f8e4b8bcmr374938085a.79.1761645188161; Tue, 28 Oct 2025 02:53:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761645188; cv=none; d=google.com; s=arc-20240605; b=POBefQ1ELxUi5WvEHrRBpRhD5e+Qac1z10L5drAShZigHSdA9DifuSaUSwSrFHAegf ACo/DAAUqrX+wqrRBibVfkyAPO+dZx7PDuRbSKAf17WxfoA6r//agDQ6d5CUTmcWD2rq WKSgiz0qw2GrFEcKiSQMh903bca8DOBupdNQNG3qPuMJ+O/d2ThL3uxv0KKByl73oeSe 1pP2OYwQqB/2t4FqtuhKjZ2GCtb5qc04z+lcGFQ2CawwsZZM+zYHfOSA4bioGssr2ujW 1/0w/kJsVPfJYIPh+s4d5a6tNrLzsEGztJruR2porJo9WIIX/MopWhh81xzswUT1//+z MRZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=bwWsAPu09F53HQkw+rzWnA/QQDErCGaTq6HtL43n2iM=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=EDov+W4HpUEvv6Wo4B346sUxYg+WUNI1Fp0MAt7IlkZqs2ahgEpcarDsK9FSnwNbFM usEhqafdqHRC5/HqINXlPOvOIkao/QMXp5NYosc5otcuVFwspw5fGt88KNJrBHZJJbmA C+Q92/OmCSJwQjvDfbztcUdR1Qzm5yDc5ZBAoQCRGMQoEuu0sBjgdksq7vILFtI81Pck M7ZB0zVJEfDOgy4Wb4wmQE2HKfi1wn5nRHo9FBZybKC2zM8109wvEA7+KN6N4M175YOi 24V15S+Ho7M2WSj0mXUX2y3I3jpso9rJTD8sgjZyxvmk89u8b360aHP41zPk2MnExKg3 o+yg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=N8w+YI7+; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.17 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch. [109.224.244.17]) by gmr-mx.google.com with ESMTPS id af79cd13be357-89f4065c60esi7967685a.0.2025.10.28.02.53.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Oct 2025 02:53:08 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.17 as permitted sender) client-ip=109.224.244.17; Date: Tue, 28 Oct 2025 09:53:01 +0000 To: Antoine Riard From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: BIP54 implementation and test vectors Message-ID: In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 99f3d7d784ed346812a2ea228cf536b1e028b59a MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=N8w+YI7+; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.17 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) Hi Riard, Thanks for the feedback. I understand your point as asking about other cost= s besides quadratic hashing, and how the BIP54 "potentially executed" sigop limit relates to th= ose. There are indeed several other expensive operations when validating a block= : ECDSA signature verifications, FindAndDelete's vector modifications, and prevout lookups. T= his last one is related to the recently discussed limit on scriptPubKey sizes [0], as they present = a constant factor increase in the lookup cost that is not bounded by the size of the block be= ing validated. In any case the cost of these other expensive operations is completely dwar= fed by quadratic hashing. The example you give is unfortunately far from the worst case. I added you to t= he semi-private Delving thread [1] which contains the detail of the calculations for various DoS bl= ocks. 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 would t= ake a couple dozens of seconds to validate on a modern machine. By comparison, without the BIP54 s= igops limit this same effect can be achieved with 2 orders of magnitude less preparation blocks, = making the attack viable for a revenue-maximizing miner. Without the BIP54 sigops limit, over a hund= red preparation blocks also gets you a block that takes over 10 minutes to validate on a modern ma= chine. Finally, besides having diminishing returns these mitigations would also ha= ve a higher confiscatory surface [2]. The BIP54 mitigation was chosen because it pinpoints exactly t= he harmful behaviour we want to prevent, with only a minimal impact on potentially legitimate usage= [3], while making attacks of miners on their competition uneconomical as well as making the v= ery worst case largely uninteresting to an externally-motivated attacker. Best, Antoine [0]: https://gnusha.org/pi/bitcoindev/OAoV-Uev9IosyhtUCyeIhclsVq-xUBZgGFROA= LaCKZkEFRNWSqbfDsVyiXnZ8B1TxKpfxmaULuwe4WpGHLI_iMdvPr5B0gM0nDvlwrKjChc=3D@p= rotonmail.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=3DDfP7XoRxfXfq1unKBD0joffddOuTsn2Zmcng@mai= l.gmail.com/ [3]: If a miner wants to sweep more than 2500 P2PK utxos in a single non-st= andard 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 wrote: > Hi Poinsot, >=20 > Started to review a bit the code branch on inquisition, and while doing s= o I was specifically > thinking about the proposed 2500 sigops limit, and how it weights on a mu= lti-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 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 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. >=20 > This is the 1 UTXO from 32 UTXOs trade-off, I would like to draw awarenes= s 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 ha= ve 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 UTXOs ha= ve 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. >=20 > So it's a bit my interrogation about this 2500 proposal, if worst-case tr= ansactions samples binding > to the 2500 limit have been crafted to maximize the number of UTXOs fetch= es. One can make the hypothesis > that UTXO fetches are "free", but I don't think it's necessarily true, wh= ile on the other hand modern ISAs > have dedicated hashing instructions. >=20 > Current BIP54 is a bit silent if full-node performance metrics like CPU c= ycles, 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 emperical= ly observed to be downgraded. >=20 > Best, > Antoine > OTS hash: 975674252060994d92eecd63a924e7530623ee737e33c5646d382f0f8c04ec7= 4 >=20 >=20 > Le mardi 21 octobre 2025 =C3=A0 18:17:21 UTC+1, Antoine Poinsot a =C3=A9c= rit : >=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 basis to ge= nerate 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 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). > >=20 > > 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. > >=20 > > 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. > >=20 > > 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]. > >=20 > > I'm seeking feedback on these test vectors from everybody but in partic= ular developers of > > alternative Bitcoin clients, as compatibility with other Bitcoin implem= entations 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 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/bitcoinde= v/e8d7baa0-5d96-4e41-8cb5-083742c61454n%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/= PIqe0rw-nHRiIJxiJ1aK-WdO1Co9HxYIPNcey3s1VCmgziSaLWAVLhXGJqD4j8VWelXFDGTmU2x= l4u2P2u2EJBSnweRbatp2f_mkIEhF6Zo%3D%40protonmail.com.