From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 17 Oct 2025 18:21:01 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v9vcx-0004W7-TB for bitcoindev@gnusha.org; Fri, 17 Oct 2025 18:21:00 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7459106ad2bsf1324639a34.1 for ; Fri, 17 Oct 2025 18:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1760750453; x=1761355253; 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=6e3nX5oBS+BVes/FD06E78FgnfFWmvl21H7TH0ZJiUU=; b=S+TNyrzz+g2hsOlB3Fghelsn0fuHjXDJe5i7wLpJisxBJlXAl+tHyWra0o3Z7WXctb bER6RxXGlcApBX7h5brKqckpkH0MH+Zu7s9OwAr5Yu1s9IxjUw8YnEeSmJskXs2eTJbH niZvBOourTBCx3+XTdkgGD0nK2pswq5BKS5klGHTpraglvw1+z/ii0XxwMkp9oOJe6G4 cyWTsmb/SzxZjnTDnlA2T9IukBOdeD07OyMdSnqouYeD1Fs/ai58yqSrvAKezSMtL3Ot vWUghHJvZq1LBeP7mfjYbVo4PJaR5ff98ZJrf+PHxqiiYh29a4xrYueSDx5H4cfH0shA mR7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760750453; x=1761355253; 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=6e3nX5oBS+BVes/FD06E78FgnfFWmvl21H7TH0ZJiUU=; b=ByrC5v1afrHBzlfULB4cLE7dIBrWviD2TnY7vqGh+fYQxhPepUnsQXX/Azs2T4r5xJ 15YNv3keoNzyIkvaKoeafWIJzuPMfc5TbUDUE89fvDafoCizrcWoDT/3tqvVcsikYS1+ XH+T79M2BqnWrVKW8cBclamuEBmm9nxx31/fiumeZvkdBhuy+530lGvBkODCVtUDzjVA j+c/0eOl6e8DPKknb2bmgW86EkDyGZFq1g7nwvZjMybTmuZVFz/4436v6MDoHGVR3ney toqYFkAM8jmU17vGGiDoHGzIU0vsgW0mKhDXCDRsfnRCFbiG57EjwjtyXOTza7yfp46g +a+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760750453; x=1761355253; 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=6e3nX5oBS+BVes/FD06E78FgnfFWmvl21H7TH0ZJiUU=; b=dLiN+5s31TyxTfYjnCMhcS34d1uEXCruJ4EnqbbIMSN/u3m9uQ+7YhDi/mrNwX2yJM kqG11aSI+0HAXJ0Y/W1/VJT3Jqid+v7wMOkt+cnV+FxBmKl00wGMCWhLYdjbxdzQ7hGX AHhVNIl3WiXHRY6n+16zlA7T2h875nDsTxEXFVrRM4kVMBGIikHQHaeMecbSc9xOQMxi 1jTLV1TZZqRiUnr5SssnuPxkRomSkNy+nbXhcsdvAidRk/HeuGZXDhznPYSyd2fMZyKZ 1aDNCs3Jz/TrcBxpdVymzB3l086i9QZtjfF8GbM8OjuC7glIpeZQwch0rYk7/07c4A3i 7kRA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW6NqRBBMG0TRfsmEbHjEPZjdSAR8rAb5ikDE64nEcgweqRP1Rh5V0+lHBleddbg6WHHQMU3rtBvLas@gnusha.org X-Gm-Message-State: AOJu0Yy3cAy+lUZbDl8gxOJUCksjLXAODLOetaKHNpdAxMM6zuDmnoJd V6PCfyjbDt71alq4EUM18N/lqf4JUbMxbysvVUyHdxUK99ZuPkO/Ae/r X-Google-Smtp-Source: AGHT+IHZPFrvFD2+aO5QxIBkk+15WHaXlYpsmPPBnlPTtYLaILKJeXDezUBlu9qItxss56VcP5DTEA== X-Received: by 2002:a05:6870:96a2:b0:371:a0d:cee2 with SMTP id 586e51a60fabf-3c98d0b41e2mr2286785fac.29.1760750453457; Fri, 17 Oct 2025 18:20:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd7jWchsB9Fs1lpLahD4nG07vS3SGOR1ro9H1nJA+CuXrw==" Received: by 2002:a05:6871:7387:b0:35c:11ef:41d0 with SMTP id 586e51a60fabf-3c97529d027ls1484382fac.2.-pod-prod-07-us; Fri, 17 Oct 2025 18:20:49 -0700 (PDT) X-Received: by 2002:a05:6808:30a2:b0:43f:27bb:78c2 with SMTP id 5614622812f47-443a2e9129bmr2537460b6e.10.1760750449339; Fri, 17 Oct 2025 18:20:49 -0700 (PDT) Received: by 2002:a0d:c203:0:b0:74f:1486:e2a9 with SMTP id 00721157ae682-78372c930fams7b3; Fri, 17 Oct 2025 18:01:16 -0700 (PDT) X-Received: by 2002:a05:690c:6010:b0:742:a0be:e3f1 with SMTP id 00721157ae682-7836d180437mr52244257b3.13.1760749275644; Fri, 17 Oct 2025 18:01:15 -0700 (PDT) Date: Fri, 17 Oct 2025 18:01:15 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <5135a031-a94e-49b9-ab31-a1eb48875ff2n@googlegroups.com> In-Reply-To: References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <961e3c3a-a627-4a07-ae81-eb01f7a375a1n@googlegroups.com> Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_170950_622981429.1760749275310" 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_170950_622981429.1760749275310 Content-Type: multipart/alternative; boundary="----=_Part_170951_480340398.1760749275310" ------=_Part_170951_480340398.1760749275310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, Thanks to the annex covered by the signature, I don't see how the concern= =20 about limiting the extensibility of bitcoin script with future (post-quantum)=20 cryptographic schemes. Previous proposal of the annex were deliberately designed with=20 variable-length fields to flexibly accomodate a wide range of things. I believe there is one thing that has not been proposed to limit=20 unpredictable utterance of spams on the blockchain, namely congestion control of categories of=20 outputs (e.g "fat" scriptpubkeys). Let's say P a block period, T a type of scriptpubkey and L= =20 a limiting threshold for the number of T occurences during the period P. Beyond the L= =20 threshold, any additional T scriptpubkey is making the block invalid. Or alternatively,=20 any additional T generating / spending transaction must pay some weight penalty... Congestion control, which of course comes with its lot of shenanigans, is= =20 not very a novel idea as I believe it has been floated few times in the context of lightning= =20 to solve mass closure, where channels out-priced at current feerate would have their=20 safety timelocks scale ups. No need anymore to come to social consensus on what is quantitative "spam"= =20 or not. The blockchain would automatically throttle out the block space spamming transaction.=20 Qualitative spam it's another question, for anyone who has ever read shannon's theory of communication=20 only effective thing can be to limit the size of data payload. But probably we're kickly back to a= =20 non-mathematically solvable linguistical question again [0]. Anyway, in the sleeping pond of consensus fixes fishes, I'm more in favor= =20 of prioritizing a timewarp fix and limiting dosy spends by old redeem scripts, rather than= =20 engaging in shooting ourselves in the foot with ill-designed "spam" consensus mitigations. [0] If you have a soul of logician, it would be an interesting=20 demonstration to come with to establish that we cannot come up with mathematically or=20 cryptographically consensus means to solve qualitative "spam", which in a very pure sense is a linguistical= =20 issue. Best, Antoine OTS hash: 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e4999 Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poinsot a =C3=A9= crit : > Hi, > > This approach was discussed last year when evaluating the best way to=20 > mitigate DoS blocks in terms > of gains compared to confiscatory surface. Limiting the size of created= =20 > scriptPubKeys is not a > sufficient mitigation on its own, and has a non-trivial confiscatory=20 > surface. > > One of the goal of BIP54 is to address objections to Matt's earlier=20 > proposal, notably the (in my > opinion reasonable) confiscation concerns voiced by Russell O'Connor.=20 > Limiting the size of > scriptPubKeys would in this regard be moving in the opposite direction. > > Various approaches of limiting the size of spent scriptPubKeys were=20 > discussed, in forms that would > mitigate the confiscatory surface, to adopt in addition to (what=20 > eventually became) the BIP54 sigops > limit. However i decided against including this additional measure in=20 > BIP54 because: > - of the inherent complexity of the discussed schemes, which would make i= t=20 > hard to reason about > constructing transactions spending legacy inputs, and equally hard to=20 > evaluate the reduction of > the confiscatory surface; > - more importantly, there is steep diminishing returns to piling on more= =20 > mitigations. The BIP54 > limit on its own prevents an externally-motivated attacker from *unevenly= *=20 > stalling the network > for dozens of minutes, and a revenue-maximizing miner from regularly=20 > stalling its competitions > for dozens of seconds, at a minimized cost in confiscatory surface.=20 > Additional mitigations reduce > the worst case validation time by a smaller factor at a higher cost in=20 > terms of confiscatory > surface. It "feels right" to further reduce those numbers, but it's less= =20 > clear what the tangible > gains would be. > > Furthermore, it's always possible to get the biggest bang for our buck in= =20 > a first step and going the > extra mile in a later, more controversial, soft fork. I previously floate= d=20 > the idea of a "cleanup > v2" in private discussions, and i think besides a reduction of the maximu= m=20 > scriptPubKey size it > should feature a consensus-enforced maximum transaction size for the=20 > reasons stated here: > > https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/17= 32/8.=20 > I wouldn't hold my > breath on such a "cleanup v2", but it may be useful to have it documented= =20 > somewhere. > > I'm trying to not go into much details regarding which mitigations were= =20 > considered in designing > BIP54, because they are tightly related to the design of various DoS=20 > blocks. But i'm always happy to > rehash the decisions made there and (re-)consider alternative approaches= =20 > on the semi-private Delving > thread [0] dedicated to this purpose. Feel free to ping me to get access= =20 > if i know you. > > Best, > Antoine Poinsot > > [0]: https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711 > > > > > On Friday, October 17th, 2025 at 1:12 PM, Brandon Black < > fre...@reardencode.com> wrote: > > >=20 > >=20 > > On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote: > >=20 > > > But also given that there are essentially no violations and no reason= =20 > to > > > expect any I'm not sure the proposal is worth time relative to fixes = of > > > actual moderately serious DOS attack issues. > >=20 > >=20 > > I believe this limit would also stop most (all?) of PortlandHODL's > > DoSblocks without having to make some of the other changes in GCC. I > > think it's worthwhile to compare this approach to those proposed by > > Antoine in solving these DoS vectors. > >=20 > > Best, > >=20 > > --Brandon > >=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/aPJ3w6bEoaye3WJ6%40console. > --=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/= 5135a031-a94e-49b9-ab31-a1eb48875ff2n%40googlegroups.com. ------=_Part_170951_480340398.1760749275310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list,

Thanks to the annex covered by the signature, I don't s= ee how the concern about limiting
the extensibility of bitcoin script = with future (post-quantum) cryptographic schemes.
Previous proposal of= the annex were deliberately designed with variable-length fields
to f= lexibly accomodate a wide range of things.

I believe there is on= e thing that has not been proposed to limit unpredictable utterance
of= spams on the blockchain, namely congestion control of categories of output= s (e.g "fat"
scriptpubkeys). Let's say P a block period, T a type of s= criptpubkey and L a limiting
threshold for the number of T occurences = during the period P. Beyond the L threshold, any
additional T scriptpu= bkey is making the block invalid. Or alternatively, any additional
T g= enerating / spending transaction must pay some weight penalty...

Congestion control, which of course comes with its lot of shenanigans, is = not very a novel
idea as I believe it has been floated few times in th= e context of lightning to solve mass
closure, where channels out-price= d at current feerate would have their safety timelocks scale
ups.

No need anymore to come to social consensus on what is quantitative = "spam" or not. The blockchain
would automatically throttle out the blo= ck space spamming transaction. Qualitative spam it's another
question,= for anyone who has ever read shannon's theory of communication only effect= ive thing can
be to limit the size of data payload. But probably we're= kickly back to a non-mathematically solvable
linguistical question ag= ain [0].

Anyway, in the sleeping pond of consensus fixes fishes,= I'm more in favor of prioritizing
a timewarp fix and limiting dosy sp= ends by old redeem scripts, rather than engaging in shooting
ourselves= in the foot with ill-designed "spam" consensus mitigations.

[0]= If you have a soul of logician, it would be an interesting demonstration t= o come with
to establish that we cannot come up with mathematically or= cryptographically consensus means
to solve qualitative "spam", which = in a very pure sense is a linguistical issue.

Best,
Antoine=
OTS hash: 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0= e4999
Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poinsot a =C3= =A9crit=C2=A0:
https://delvin= gbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8. I woul= dn't hold my
breath on such a "cleanup v2", but it may be useful to have i= t documented somewhere.

I'm trying to not go into much details regarding which mitigations = were considered in designing
BIP54, because they are tightly related to the design of various DoS bl= ocks. But i'm always happy to
rehash the decisions made there and (re-)consider alternative approache= s on the semi-private Delving
thread [0] dedicated to this purpose. Feel free to ping me to get acces= s if i know you.

Best,
Antoine Poinsot

[0]: https://delvingbitcoin.org/t= /worst-block-validation-time-inquiry/711




On Friday, October 17th, 2025 at 1:12 PM, Brandon Black <fre...@reardencode.com> wrote:

>=20
>=20
> On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote:
>=20
> > But also given that there are essentially no violations and n= o reason to
> > expect any I'm not sure the proposal is worth time relati= ve to fixes of
> > actual moderately serious DOS attack issues.
>=20
>=20
> I believe this limit would also stop most (all?) of PortlandHODL&#= 39;s
> DoSblocks without having to make some of the other changes in GCC.= I
> think it's worthwhile to compare this approach to those propos= ed by
> Antoine in solving these DoS vectors.
>=20
> Best,
>=20
> --Brandon
>=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/aPJ3w6bEoaye3WJ6%40c= onsole.

--
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/5135a031-a94e-49b9-ab31-a1eb48875ff2n%40googlegroups.com.
------=_Part_170951_480340398.1760749275310-- ------=_Part_170950_622981429.1760749275310--