From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 22 Oct 2025 02:56:07 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.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 1vBVZe-0001Aw-4l for bitcoindev@gnusha.org; Wed, 22 Oct 2025 02:56:07 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-34c14f3b822sf18599810fac.1 for ; Wed, 22 Oct 2025 02:56:05 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761126958; cv=pass; d=google.com; s=arc-20240605; b=lkXcCIOAG+FWxANZ/q/zutdP7YjZocX6T9l9GB6nOfOc/IQtp+csB4JCjBjHS8RUK2 OlFYZ53izD0fw+yEh29BC0G6vso2/7h0xV7tvsGhWrLTI5m0mbGJafyyVzdCzAO7D6fr NLnQ9ppzB0h5O1TqJhng4v9vhS13SHbgNxlQ+juxTEvFqEpapb6gTtWSoInsegEDPLPI +2J38WCsJxmb2gS33AEzA0rv+mWmheutCLe3eZpgsLNIw9BSr/NlO1WvlFCje+FQzDTp JzHmY7Orzyo2mUYHz25tkOtZORQy9IL2LaQBaq2Okms30ZHaw79J2x8c5z7huuH4h0df dDDg== 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=vRwMi+3g/U272pqhPFJxPqk2Ha1rq0f+zsZtrf8i/V4=; fh=qELkBEwaMLuob1huhtLo0xV+rGFBom9e7WhQqCELQMc=; b=EF10o0Yniu9F3sRHRy4Pym/10BybvAEmlV4QHn625m2s0H2aKk0XOPNwda36GVG7ua gT6TDEHA+KP3P68MOsW6b6uGV4ZaQ3r29SlZw+3qbN8KbuSox0z7MnXMwxhdd3ZD/BLa qDNSCUVY+OLP9Bk3/NqA5v/DtKsmYx5J+L6tQIwUChn/gJA5qPDUOjzI9Pa5zlv/rY1C AutQ1UoI1/MAxVSmov6X5REoA0vp51DqbBTdQV5472oBRtiU7obrG9tmA5i2EqxguvlO CI/9LQeGi8i75PE59nrt/ewaZ+MeJGe7NXhSrwD83togmxHBS/Cvgn20BVZeToKakF9J IOXw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=l83WUYH2; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) smtp.mailfrom=moonsettler@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=1761126958; x=1761731758; 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=vRwMi+3g/U272pqhPFJxPqk2Ha1rq0f+zsZtrf8i/V4=; b=gNl7JZE2k3ptPihC+WDaN7BjyZtsy6plRzj6almbvIK+SA2ZqMqWyig4TdbYhlSrzg A6qI92jubd3CGow49H0De/6k7jCGWiGHNrwoz1ASU8rCbPjjjuMSIOFpr6QNDWX3xEYX +C2M6Q5h4bioisQYN5wnxbgYSg6hPUGZMcyGqUfQg5vPks1VHMXHFr/DEi1IWImmRfoH AsqcPcbvLnMxrMZZoH2gpe/a/OIah7Xn3+WKGMEvUbNBEcvQ/XW8XSEed669ZlifQ/tD wgYv8HtYRrfAKvJJBDiM2J2va29iqruUYjI0Qg0igwrtDQHszADKLcEM++qrtL3K+mxp nVtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761126958; x=1761731758; 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=vRwMi+3g/U272pqhPFJxPqk2Ha1rq0f+zsZtrf8i/V4=; b=qeyK2Hv8bXvWt2xSWaHf04pKOuOAI56sPa+AfpLbdEMtbBN0Mxy7Bxg6DWz8mrSiR3 jcuFyRU8mEZly4sfWZ9OkqkY9XicBnnlm39QHtER0CweQm2ncJb7RlrXAMAfh0M6vz70 AH2DRORMgbfPY4Mtc2zAZDF1mIeqWKssNFEIgHB/sWJIAsaXewJ4Vg5cJgT1XU2OogwK FaP4fP+/qHysyY6Q/UzHbCnRdfAl3fNjmWB7uVEA7E7ESOre6xEagzVagMarEsJLEiEW nSBPpz28cWDSX0RWm1Y/1bNKJ5Q8eylqR/gLbp7yu7hESp5g9se3hh7k2eeTfGus8qP8 I59w== X-Forwarded-Encrypted: i=2; AJvYcCVxF0blCCToz2Tsy/rYMe64ALDWJnPWl/txOlWknVl0/I1CNflyUo+C6+uBWHJOlFstaHL6Ze3kI8+x@gnusha.org X-Gm-Message-State: AOJu0Ywsk0jpYKwxBLaDGwaNnhkmhkI3mjhrQsuZ8BXB3qgQCRBkiblo SnkfCYxcoOP5dIwcAQQKN26rTpTRYgXymW749VvxxUKgcR3kYKAxIpaA X-Google-Smtp-Source: AGHT+IHPFwnuzyuI3ovqpe5r6uadj/U1pGm0tAUr+cO6rJRxJ03Yhu9028oP7nB5GnDXt5ThyAhCJw== X-Received: by 2002:a05:6808:3a07:b0:441:8f74:fd2 with SMTP id 5614622812f47-443a30c6b46mr9577653b6e.63.1761126958518; Wed, 22 Oct 2025 02:55:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd7o9OI+dkEo9qKzId5Lbg6zM4iiKzvsMbFSk4cvNYDR0Q==" Received: by 2002:a4a:bb18:0:b0:650:920f:3c29 with SMTP id 006d021491bc7-651be408926ls3346995eaf.0.-pod-prod-08-us; Wed, 22 Oct 2025 02:55:54 -0700 (PDT) X-Received: by 2002:a05:6808:2393:b0:438:3680:d66e with SMTP id 5614622812f47-443a2ff4933mr8311102b6e.39.1761126953932; Wed, 22 Oct 2025 02:55:53 -0700 (PDT) Received: by 2002:a05:6504:1396:b0:2cb:cee6:b4b3 with SMTP id a1c4a302cd1d6-2d035ccc2a2msc7a; Wed, 22 Oct 2025 01:07:53 -0700 (PDT) X-Received: by 2002:a05:651c:1606:b0:372:9bf0:aec9 with SMTP id 38308e7fff4ca-37797722311mr59558791fa.8.1761120470697; Wed, 22 Oct 2025 01:07:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761120470; cv=none; d=google.com; s=arc-20240605; b=YELUCzk2yrk/bgoKWDUcVYTa3AfH/7n2IwIpXdiZ0ybQG8Md2WyB0x/blrvWe16EiQ neSbzEg1h6dlbLkADM/W4C4GQw5ilVPPx1ZCH1u47o5mESV5FRW9RYmNmIdsnnoX1OaF GxaaP9khqi+CBbGo+qSO+kbG5SVoiFAFLyQeZuM9KnIZrG38jZTgj/beJDIiEKAbu9ac KcydzlC7FomMfPeTm1Tk875B6xzPtIGK5DlRUxZ9XivOlnPq5GFlXxImejv0pr+5QjN8 s5raSAU9fdnuX7ZH9ISCl+ueDuD3f+lnScigQo+7LnVubkpi9xOKcYauPfNHLKSCASRo o9UA== 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=QzDNUydoyZ3jmCRKPQ7imp9JYyHej/eIgUV9e/3WEqU=; fh=Yq3ud+3qRm/huYxo70n2Iv8FSRuYgo9ERl1dwhQIx8Q=; b=jOumqb4boOlgtyGcxaTYdT514JS+5SOweVMFDuk/u5S3zUaK3YxqJCaNSw23760QeP yn/PcicmHA7Rot8KCBB3jsw2dT6oLnVqyk5YC7gXtpQE1cxoBnKifHJum1TRARxfdYKl vjpd5z+O1/Bz0tDpE453VjZDnqxZzSPNdku8+m5ZyieFJ0XvVVHZ+LARt9TTssyNU3co sg9GOl4hN8P69vM/hv6oB7MvNish6YugyWapSmgmcixhMe9vHTHhu0ixRdtovdQS6ALR OWz8/Jx6XZlGFIRQ/VuOLq3fDldsX2lbd1X8WXUkHSlc0eapuTZ3Cz8+MaCRxqOTcHuW StnA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=l83WUYH2; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch. [185.70.43.167]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-377a90f4a2esi4242231fa.0.2025.10.22.01.07.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Oct 2025 01:07:50 -0700 (PDT) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) client-ip=185.70.43.167; Date: Wed, 22 Oct 2025 08:07:44 +0000 To: PortlandHODL From: "'moonsettler' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. Message-ID: In-Reply-To: <78475572-3e52-44e4-8116-8f1a917995a4n@googlegroups.com> References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <961e3c3a-a627-4a07-ae81-eb01f7a375a1n@googlegroups.com> <5135a031-a94e-49b9-ab31-a1eb48875ff2n@googlegroups.com> <78475572-3e52-44e4-8116-8f1a917995a4n@googlegroups.com> Feedback-ID: 38540639:user:proton X-Pm-Message-ID: 33ecec30f2447f74d24c328c432e1057b185224d MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: moonsettler@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=l83WUYH2; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.167 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: moonsettler Reply-To: moonsettler 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 (-) > Confiscation is a problem because of presigned transactions Allow 10000 bytes of total scriptPubKey size in each block counting only th= ose outputs that are larger than x (520 as proposed). The code change is pretty minimal from the most obvious implementation of t= he original rule. That makes it technically non-confiscatory. Still non-standard, but if anyo= ne out there so obnoxiously foot-gunned themselves, they can't claim they w= ere rugged by the devs. BR, moonsettler On Saturday, October 18th, 2025 at 3:15 PM, PortlandHODL = wrote: > Hey, >=20 > First, thank you to everyone who responded, and please continue to do so.= There were many thought provoking responses and this did shift my perspect= ive quite a bit from the original post, which in of itself was the goal to = a degree. >=20 > I am currently only going to respond to all of the current concerns. Acks= ; though I like them will be ignored unless new discoveries are included. >=20 > Tl;dr (Portlands Perspective) > - Confiscation is a problem because of presigned transactions > - DoS mitigation could also occur through marking UTXOs as unspendable if= > 520 bytes, this would preserve the proof of publication. > - Timeout / Sunset logic is compelling > - The (n) value of acceptable needed bytes is contentious with the lower = suggested limit being 67 > - Congestion control is worth a look? >=20 > Next Step: > - Deeper discussion at the individual level: Antoine Poinsot and GCC over= lap? > - Write an implementation. > - Decide to pursue BIP >=20 > Responses >=20 > Andrew Poelstra: > > There is a risk of confiscation of coins which have pre-signed but > > unpublished transactions spending them to new outputs with large > > scriptPubKeys. Due to long-standing standardness rules, and the presenc= e > > of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any > > such transactions exist. >=20 > PortlandHODL: This is a risk that can be incurred and likely not possible= to mitigate as there could be possible chains of transactions so even when= recursively iterating over a chain there is a chance that a presigned brea= ks this rule. Every idea I have had from block redemption limits on prevout= s seems to just be a coverage issue where you can make the confiscation les= s likely but not completely mitigated. >=20 > Second, there are already TXs that effectively have been confiscated at t= he policy level (P2SH Cleanstack violation) where the user can not find any= miner with a policy to accept these into their mempool. (3 years) >=20 > /dev /fd0 > > so it would be great if this was restricted to OP_RETURN >=20 > PortlandHODL: I reject this completely as this would remove the UTXOset o= mission for the scriptPubkey and encourage miners to subvert the OP_RETURN = restriction and instead just use another op_code, this also do not hit on s= ome of the most important factors such as DoS mitigation and legacy script = attack surface reduction. >=20 > Peter Todd > > NACK ... >=20 > PortlandHODL: You NACK'd for the same reasons that I stated in my OP, wit= hout including any additional context or reasoning. >=20 > jeremy > > I think that this type of rule is OK if we do it as a "sunsetting" rest= riction -- e.g. a soft fork active for the next N blocks (N =3D e.g. 2 year= s, 5 years, 10 years). >=20 > If action is taken, this is the most reasonable approach. Alleviating con= fiscatory concerns through deferral. >=20 > > You can argue against this example probably, but it is worth considerin= g that absence of evidence of use is not evidence of absence of use and I m= yself feel that overall our understanding of Bitcoin transaction programmin= g possibilities is still early. If you don't like this example, I can give = you others (probably). >=20 > Agreed and this also falls into the reasoning for deciding to utilize poi= nt 1 in your response. My thoughts on this would be along the lines of proo= f of publication as this change only has the effect of stripping away the e= xecutable portion of a script between 521 and 10_000 bytes or the published= data portion if > 10_000 bytes which the same data could likely be publish= ed in chunked segments using outpoints. >=20 > Andrew Poelstra: > > Aside from proof-of-publication (i.e. data storage directly in the UTXO > > set) there is no usage of script which can't be equally (or better) > > accomplished by using a Segwit v0 or Taproot script. >=20 > This sums up the majority of future usecase concern >=20 > Anthony Towns: > > (If you restricted the change to only applying to scripts that used > non-push operators, that would probably still provide upgrade flexibility > while also preventing potential script abuses. But it wouldn't do anythin= g > to prevent publishing data) >=20 > Could this not be done as segments in multiple outpoints using a coordina= tion outpoint? I fail to see why publication proof must be in a single chun= k. This does though however bring another alternative to mind, just making = these outpoints unspendable but not invalidate the block through inclusion.= .. >=20 > > As far as the "but contiguous data will be regulated more strictly" > argument goes; I don't think "your honour, my offensive content has > strings of 4d0802 every 520 bytes >=20 > Correct, this was never meant to resolve this issue. >=20 > Luke Dashjr: > > If we're going this route, we should just close all the gaps for the im= mediate future: >=20 > To put it nicely, this is completely beyond the scope of what is being pr= oposed. >=20 > Guus Ellenkamp: > > If there are really so few OP_RETURN outputs more than 144 bytes, then > why increase the limit if that change is so controversial? It seems > people who want to use a larger OP_RETURN size do it anyway, even with > the current default limits. >=20 > Completely off topic and irrelevant >=20 > Greg Tonoski: > > Limiting the maximum size of the scriptPubKey of a transaction to 67 by= tes. >=20 > This leave no room to deal with broken hashing algorithms and very little= future upgradability for hooks. The rest of these points should be merged = with Lukes response and either hijack my thread or start a new one with the= increased scope, any approach I take will only be related to the ScriptPub= key >=20 > Keagan McClelland: > > Hard NACK on capping the witness size as that would effectively ban lar= ge scripts even in the P2SH wrapper which undermines Bitcoin's ability to b= e an effectively programmable money. >=20 > This has nothing to do with the witness size or even the P2SH wrapper >=20 > Casey Rodarmor: > > I think that "Bitcoin could need it in the future?" might be a good eno= ugh > reason not to do this. >=20 > > Script pubkeys are the only variable-length transaction fields which ca= n be > covered by input signatures, which might make them useful for future soft > forks. I can imagine confidential asset schemes or post-quantum coin reco= very > schemes requiring large proofs in the outputs, where the validity of the = proof > determined whether or not the transaction is valid, and thus require the > proofs to be in the outputs, and not just a hash commitment. >=20 > Would the ability to publish the data alone be enough? Example make the o= utput unspendable but allow for the existence of the bytes to be covered th= rough the signature? >=20 >=20 > Antoine Poinsot: > > Limiting the size of created scriptPubKeys is not a sufficient mitigati= on on its own > I fail to see how this would not be sufficient? To DoS you need 2 things = inputs with ScriptPubkey redemptions + heavy op_codes that require unique c= hecks. Example DUPing stack element again and again doesn't work. This then= leads to the next part is you could get up to unique complex operations wi= th the current (n) limit included per input. >=20 > > One of the goal of BIP54 is to address objections to Matt's earlier pro= posal, notably the (in my > opinion reasonable) confiscation concerns voiced by Russell O'Connor. Lim= iting the size of > scriptPubKeys would in this regard be moving in the opposite direction. >=20 > Some notes is I would actually go as far as to say the confiscation risk = is higher with the TX limit proposed in BIP54 as we actually have proof of = redemption of TXs that break that rule and the input set to do this already= exists on-chain no need to even wonder about the whole presigned. bb41a757= f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 >=20 > Please let me know if I am incorrect on any of this. >=20 > > Furthermore, it's always possible to get the biggest bang for our buck = in a first step >=20 > Agreed on bang for the buck regarding DoS. >=20 > My final point here would be that I would like to discuss more, and this = is response is from the initial view of your response and could be incomple= te or incorrect, This is just my in the moment response. >=20 > Antoine Riard: > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more in fav= or of prioritizing > a timewarp fix and limiting dosy spends by old redeem scripts >=20 > The idea of congestion control is interesting, but this solution should s= ignificantly reduce the total DoS severity of known vectors. >=20 > On Saturday, October 18, 2025 at 2:25:18=E2=80=AFAM UTC-7 Greg Maxwell wr= ote: >=20 > > Limits on block construction that cross transactions make it harder to = accurately estimate fees and greatly complicate optimal block construction-= - the latter being important because smarter and more computer powered mini= ng code generating higher profits is a pro centralization factor. > >=20 > > In terms of effectiveness the "spam" will just make itself indistinguis= hable from the most common transaction traffic from the perspective of such= metrics-- and might well drive up "spam" levels because the higher embeddi= ng cost may make some of them use more transactions. The competition for th= ese buckets by other traffic could make it effectively a block size reducti= on even against very boring ordinary transactions. ... which is probably no= t what most people want. > >=20 > > I think it's important to keep in mind that bitcoin fee levels even at = 0.1s/vb are far beyond what other hosting services and other blockchains co= st-- so anyone still embedding data in bitcoin *really* want to be there fo= r some reason and aren't too fee sensitive or else they'd already be using = something else... some are even in favor of higher costs since the high fee= s are what create the scarcity needed for their seigniorage. > >=20 > > But yeah I think your comments on priorities are correct. > >=20 > >=20 > >=20 > > On Sat, Oct 18, 2025 at 1:20=E2=80=AFAM Antoine Riard wrote: > >=20 > > > Hi list, > > >=20 > > > Thanks to the annex covered by the signature, I don't see how the con= cern about limiting > > > the extensibility of bitcoin script with future (post-quantum) crypto= graphic schemes. > > > Previous proposal of the annex were deliberately designed with variab= le-length fields > > > to flexibly accomodate a wide range of things. > > >=20 > > > I believe there is one thing that has not been proposed to limit unpr= edictable utterance > > > of spams on the blockchain, namely congestion control of categories o= f outputs (e.g "fat" > > > scriptpubkeys). Let's say P a block period, T a type of scriptpubkey = and L a limiting > > > threshold for the number of T occurences during the period P. Beyond = the L threshold, any > > > additional T scriptpubkey is making the block invalid. Or alternative= ly, any additional > > > T generating / spending transaction must pay some weight penalty... > > >=20 > > > 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 the context of lig= htning to solve mass > > > closure, where channels out-priced at current feerate would have thei= r safety timelocks scale > > > ups. > > >=20 > > > No need anymore to come to social consensus on what is quantitative "= spam" or not. The blockchain > > > would automatically throttle out the block space spamming transaction= . Qualitative spam it's another > > > question, for anyone who has ever read shannon's theory of communicat= ion only effective thing can > > > be to limit the size of data payload. But probably we're kickly back = to a non-mathematically solvable > > > linguistical question again [0]. > > >=20 > > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more in f= avor of prioritizing > > > a timewarp fix and limiting dosy spends by old redeem scripts, rather= than engaging in shooting > > > ourselves in the foot with ill-designed "spam" consensus mitigations. > > >=20 > > > [0] If you have a soul of logician, it would be an interesting demons= tration to come with > > > to establish that we cannot come up with mathematically or cryptograp= hically consensus means > > > to solve qualitative "spam", which in a very pure sense is a linguist= ical issue. > > >=20 > > > Best, > > > Antoine > > > OTS hash: 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0= e4999 > > > Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poinsot a = =C3=A9crit : > > >=20 > > > > Hi, > > > >=20 > > > > This approach was discussed last year when evaluating the best way = to mitigate DoS blocks in terms > > > > of gains compared to confiscatory surface. Limiting the size of cre= ated scriptPubKeys is not a > > > > sufficient mitigation on its own, and has a non-trivial confiscator= y surface. > > > >=20 > > > > One of the goal of BIP54 is to address objections to Matt's earlier= proposal, notably the (in my > > > > opinion reasonable) confiscation concerns voiced by Russell O'Conno= r. Limiting the size of > > > > scriptPubKeys would in this regard be moving in the opposite direct= ion. > > > >=20 > > > > Various approaches of limiting the size of spent scriptPubKeys were= discussed, in forms that would > > > > mitigate the confiscatory surface, to adopt in addition to (what ev= entually became) the BIP54 sigops > > > > limit. However i decided against including this additional measure = in BIP54 because: > > > > - of the inherent complexity of the discussed schemes, which would = make it hard to reason about > > > > constructing transactions spending legacy inputs, and equally hard = to evaluate the reduction of > > > > the confiscatory surface; > > > > - more importantly, there is steep diminishing returns to piling on= more mitigations. The BIP54 > > > > limit on its own prevents an externally-motivated attacker from *un= evenly* stalling the network > > > > for dozens of minutes, and a revenue-maximizing miner from regularl= y stalling its competitions > > > > for dozens of seconds, at a minimized cost in confiscatory surface.= Additional mitigations reduce > > > > the worst case validation time by a smaller factor at a higher cost= in terms of confiscatory > > > > surface. It "feels right" to further reduce those numbers, but it's= less clear what the tangible > > > > gains would be. > > > >=20 > > > > Furthermore, it's always possible to get the biggest bang for our b= uck in a first step and going the > > > > extra mile in a later, more controversial, soft fork. I previously = floated the idea of a "cleanup > > > > v2" in private discussions, and i think besides a reduction of the = maximum scriptPubKey size it > > > > should feature a consensus-enforced maximum transaction size for th= e reasons stated here: > > > > https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-li= mit/1732/8. I wouldn't hold my > > > > breath on such a "cleanup v2", but it may be useful to have it docu= mented somewhere. > > > >=20 > > > > 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 Do= S blocks. But i'm always happy to > > > > rehash the decisions made there and (re-)consider alternative appro= aches on the semi-private Delving > > > > thread [0] dedicated to this purpose. Feel free to ping me to get a= ccess if i know you. > > > >=20 > > > > Best, > > > > Antoine Poinsot > > > >=20 > > > > [0]: https://delvingbitcoin.org/t/worst-block-validation-time-inqui= ry/711 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > On Friday, October 17th, 2025 at 1:12 PM, Brandon Black wrote: > > > >=20 > > > > > > > > > > > > > > > On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote: > > > > > > > > > > > But also given that there are essentially no violations and no = reason to > > > > > > expect any I'm not sure the proposal is worth time relative to = fixes of > > > > > > actual moderately serious DOS attack issues. > > > > > > > > > > > > > > > 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. > > > > > > > > > > Best, > > > > > > > > > > --Brandon > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Googl= e 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/b= itcoindev/aPJ3w6bEoaye3WJ6%40console. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. > >=20 > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/5135a031-a94e-49b9-ab31-a1eb48875ff2n%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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/78475572-3e52-44e4-8116-8f1a917995a4n%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/= o5Ewtxc0zflnX5G_CXkntdAO8ZRi_seKPovZ-bJs8Lq-CY-ClLMyINd-eQ0vcIETWMdD5fCE_31= HbTBy3U7iEopZjT0H5LNTXTc3eAL6hLE%3D%40protonmail.com.