From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 18 Oct 2025 10:01:36 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vAAJC-000604-0e for bitcoindev@gnusha.org; Sat, 18 Oct 2025 10:01:36 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-34c14f3b822sf9582645fac.1 for ; Sat, 18 Oct 2025 10:01:33 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1760806888; cv=pass; d=google.com; s=arc-20240605; b=Y0/tp438d9VwRjmuXbdQHmU55WXjNgw+Zbwz0Z0Xl8Yq12dwoVlMB/zG6SpBTmeA/s LiWPhARXfW3hMZsA7A7S1TTqLqFg22+n5Gvx6ME7iwKZwuz/A6Z6R6hez14I9Mz3Gkpp 1ARSWMYVzcITZapJ4UMtq4AAn4XUTm6+ppAp0Z9lme6z+gtxRx6UDWp/MVxl8TzI6HV8 Oh6WIGpZOoVc5K4phdIn+2ix/TXm53vrCMBVYyG/Z2rPe3CoGNBYkj7LDIELTBQG6/OU N+NLiD8aukiKfjRkyCf96/PzOFMyl0CYcQCxy0t50ewHpunE1UFVCas86G3C2VIjza0/ MWdw== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=0v6mc+c+XN9WR7OIeWvo8JwJH5boZZYTmm6CAVlmhl0=; fh=xrYGd+2DAN8VJkHohZp6FhCbVA7SfaeUk8ZAF1KzUtg=; b=kNN8d1RKqXU0nDSABffLahBUAMU7cl6Ytk+YAPFmEB3TUB1Zh/LRbDvOdliBrKrAkZ 6Hx+2dFNo+hv55rY4p1SGvnz6lvsdYKLr8sHMWtcElJLsbRLp44WdS86cuonuobVLE7z 8TDvEdCa/IpAI9+x4ybJZRg06K+AbJbqP9Y25H2GMwb1FQ2Q/ELW1bGIno7AHMhhfS1L 1KDYciVrYALU5HaY6jBWBOF27ib7YV5ghzxB9+e65OgbG63lAXRzXH9d9H5r4rpajsoo riRLwTtWwEI8a0NpZJvFTWOQ5cVddk4jLP4lefuyESKSHVIsdAGvzqn9gAwKXZgjB2fN SyGA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d3ibYXFQ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::32 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1760806888; x=1761411688; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=0v6mc+c+XN9WR7OIeWvo8JwJH5boZZYTmm6CAVlmhl0=; b=SCtW4UBzMOXpb/8Gmp7ilFpOZBE6LU0hsqSsYcbsK4KLkz8HCSmUEaKocRi9615ciu hMjval0k/GgJGl8bcNWgiQgor2w1cPb9N01PopI0m4D6uB8+onZo9+sOpZ+/PLbW43eF xW4jbLiGduxbxgsh0w2v47Tr9hS5mCfx9uzXtETBjx4juvFDmXs8i/JIRItSnQebRA8X bMzYedp08VOcZ23SfJCdjoH7z7lS7OTzrUhsJSFJnFg+rn1tE4/Q8UIXPbrIuXzSXDCC UnzFYwWE9xuylFH/KV1S8DQruMUtb/5WqHnu3Z838igm1z48k5dIVUANkFsTrjyngujh i+EA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760806888; x=1761411688; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0v6mc+c+XN9WR7OIeWvo8JwJH5boZZYTmm6CAVlmhl0=; b=cYNhNl3loCWCMdY8GLgWGNby/X4Wy6TDbQKGk1t3tzQCZJUPil2DxH6qzDzZBzuZB2 g1lmgdnilwlX+cc70IOLCX8903w1U2V5TDYRgJcq50MjyTEnff6yz4qIRVovb7efgSDI AZstgSde21CFaRQJUzF+1cj3hL8KJCHspwWrwuK2kWoi9NPvKrJXICi6lavvoKFxvtIT 0RskxD/jXovgJutNQsVrAZlOXvhtpc6O1NnaLQ5ndK7jeHtMH281LU+squerJ18BM5yv HwENvgRQ/HXa308TjCVqFw4Oz/6YyXZId24zEOCzLqw8MTCj0k45G1I5Gp7B6Oyq6902 l42Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760806888; x=1761411688; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=0v6mc+c+XN9WR7OIeWvo8JwJH5boZZYTmm6CAVlmhl0=; b=XTU8HAp9IcjMLBJYi0xKFt+mtNYHVk7Lh2Jvknfrgro8JBiKVhqe4tDnwheTsyGK6z F3n6vt/OYQc7VrA9PRKUn1My3aQrAcZQQon//x2G4rqK5VsmZzR8R6a5oClRbo2QwaPf /qaS3ebZy1CFeQLIDgQV1zh2XvqTz7zDD0aKraq21/GLLoAWWIVEuG0l8NVjq4h4OXTm NtSAB753PBSv5P1Mr/+LVNq5rl/nBO2FmOwTirWgYPxVEXiAtSj4VEZCkPrDYHmZBnmF VhL+kROevC61AzMj3DVwmPAr5ei1xjFGAHcCUqFnPt6BCbRH/VoaUz4qJ+5URzA97LaN Uv6g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXpyxYgEmpakcBuYKlXLVPMFGXRnvRZxQV6XkU28ddN7KA7eRInEmmGK3rMmsgIhgCeFCr+E+C8j1o5@gnusha.org X-Gm-Message-State: AOJu0Yz0Iy4rlRjc+gC+hjuqMrZibxOEYx2SkK16e8SPEzDNNmA++6LY OEF9N7XAyHTMwJe/eGWY00UQ8MHKO2a4wnl0qLQ0BTalRifY8l0SYlwE X-Google-Smtp-Source: AGHT+IGWqUMrtKCqlZITvJ/kHONGFCO8D9CAcSl/zcGgDyGO9MZhE4CLGewDYeorjpHfpjevRZxiFQ== X-Received: by 2002:a05:6871:7296:b0:31d:8c7b:401d with SMTP id 586e51a60fabf-3c98d17d31cmr3285067fac.46.1760806887607; Sat, 18 Oct 2025 10:01:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4U6hYQtleqDjWV2rY0GE9QqCGHKhO+MNxR0Ls4OugbRQ==" Received: by 2002:a05:6870:989d:b0:319:c528:28df with SMTP id 586e51a60fabf-3c97504543els1440955fac.1.-pod-prod-08-us; Sat, 18 Oct 2025 10:01:23 -0700 (PDT) X-Received: by 2002:a05:6808:1889:b0:43d:6a69:7752 with SMTP id 5614622812f47-443a2dd84ddmr3286404b6e.2.1760806883600; Sat, 18 Oct 2025 10:01:23 -0700 (PDT) Received: by 2002:a05:620a:29d0:b0:851:28d8:13e with SMTP id af79cd13be357-88f5ac07fbcms85a; Sat, 18 Oct 2025 09:54:40 -0700 (PDT) X-Received: by 2002:a05:6122:a23:b0:54b:cab1:d8b0 with SMTP id 71dfb90a1353d-5564ee407c0mr2386223e0c.2.1760806478161; Sat, 18 Oct 2025 09:54:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1760806478; cv=none; d=google.com; s=arc-20240605; b=cHoCkOzqCR/lmglwSp5ZLZmiosSRc1UVxiPgrarP91A7unhcKO5RxdASSHhjX9+LR/ zqZ6CBWpivn5j7HiOKND2WyB4o7dbB2j4WUl3nqcWneeH5EeZCKzZYJBsxEgoLKTp09n uY5pyU1naqrPHGnjYXB/GXMW66HobCP/TPNo+8sb2tiJfHP5luhexLfh2J7m62+tQhgW lvcrXHHoq1ENK/zf0o6svPP6pcl8Q6B4vUmf/cUUmnLy4TymUGq36/0fwgI0lYYbLm7X PWxc135bV5s0hKuSWwCx76wyYK8XI36Yd0S3o0GGySbPjkd3W0OSkmDzYmktMo0t0eId mxNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=uWll9dPpKqDcOifyeDlJ0fW5w/4q1VxGA4Y2j1dJMN4=; fh=Yq3ud+3qRm/huYxo70n2Iv8FSRuYgo9ERl1dwhQIx8Q=; b=b9RZKRCFM61goeImfzT+aPtCugCK1XFBebxu3dEJ28UQ9zyY0ammOn48Rv7/RnsqOv zSxLA7dAooGjsm+V51zMEkPfWV1znbqLPzRSyl98pvJNifjvhO3n5JxZwYIA/GIzJVkb 6JbbC7/DDuk8yLcbtfb2fkFmVrTloTuc3MeZcviwFCKdZiOfXY7hiITxV4l2EjdZKBa+ JSm24CoQFkrHQqrk2HmEnFp0AnA7lSlMskvbYlJgNDIdGu4h0W9+v3WqGa25wEraGyq7 cnCakP9k1oumLJ5QuJM1dALzVpuSZ/50wpRG3QxR5cehgguGtyayA4NZoElu7zl7/jsT O3cA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d3ibYXFQ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::32 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com. [2001:4860:4864:20::32]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-55661fb51e9si283274e0c.2.2025.10.18.09.54.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Oct 2025 09:54:38 -0700 (PDT) Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::32 as permitted sender) client-ip=2001:4860:4864:20::32; Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-3caae20a290so3344fac.3 for ; Sat, 18 Oct 2025 09:54:38 -0700 (PDT) X-Gm-Gg: ASbGncvQ6s9pn57EJ0TeG3T9OUPLo+g0NcieFVYbxKdtmol6x+rAp0nBFRZZp6DFPNV wWeUa4Wr3AL7RCk0yWvQwNsxvhveljwJjzKYiCYffKOvgiojb2z/x551d64f8kaMTS/5SF5ryx6 j/UK+bewgRNADmnpN6Kno6FEdVPcpxQqiqko9OQc4asEx2czBFFAlTBuc5mIv917EtUh9+1fq3B /I2N7/mxQUjZkpaW+U59KMo1rXGhNsxa6eUEVgJTYW4WO4DZhCxilYn836lr863+Fc3ZzbH4Szl frEUCvgQPOmyAZ0S0utjszTEiMaiIQsD+oY= X-Received: by 2002:a05:6870:ac21:b0:344:171c:b26b with SMTP id 586e51a60fabf-3c98d1d5e18mr3457605fac.51.1760806477184; Sat, 18 Oct 2025 09:54:37 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <78475572-3e52-44e4-8116-8f1a917995a4n@googlegroups.com> From: "/dev /fd0" Date: Sat, 18 Oct 2025 22:24:25 +0530 X-Gm-Features: AS18NWCui3WNioI2qlWHLiGQI_F1-BcdpppA3jAxPtf-KUPeM1UW5_8C4xiChKs Message-ID: Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: PortlandHODL Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000097427b064171b4d3" X-Original-Sender: alicexbtong@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d3ibYXFQ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::32 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --00000000000097427b064171b4d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi portlandhold, > PortlandHODL: I reject this completely as this would remove the UTXOset omission for the scriptPubkey Your proposed solution would affect the UTXO set negatively if someone is really motivated to use scriptpubkey for arbitrary data. They will use multiple outputs as people do with [DNS records][0]. > and encourage miners to subvert the OP_RETURN restriction and instead just use another op_code What would motivate users to follow this approach, considering that storing data in the witness is cheaper? [0]: https://asherfalcon.com/blog/posts/2 [1]: https://docs.ordinals.com/guides/batch-inscribing.html /dev/fd0 floppy disk guy On Sat, Oct 18, 2025 at 6:45=E2=80=AFPM PortlandHODL wrot= e: > Hey, > > First, thank you to everyone who responded, and please continue to do so. > There were many thought provoking responses and this did shift my > perspective quite a bit from the original post, which in of itself was th= e > goal to a degree. > > 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. > > Tl;dr (Portlands Perspective) > - Confiscation is a problem because of presigned transactions > - DoS mitigation could also occur through marking UTXOs as unspendable i= f > > 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? > > Next Step: > - Deeper discussion at the individual level: Antoine Poinsot and GCC > overlap? > - Write an implementation. > - Decide to pursue BIP > > Responses > > 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. > > 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 whe= n > recursively iterating over a chain there is a chance that a presigned > breaks this rule. Every idea I have had from block redemption limits on > prevouts seems to just be a coverage issue where you can make the > confiscation less likely but not completely mitigated. > > Second, there are already TXs that effectively have been confiscated at > the policy level (P2SH Cleanstack violation) where the user can not find > any miner with a policy to accept these into their mempool. (3 years) > > /dev /fd0 > > so it would be great if this was restricted to OP_RETURN > > PortlandHODL: I reject this completely as this would remove the UTXOset > omission for the scriptPubkey and encourage miners to subvert the OP_RETU= RN > restriction and instead just use another op_code, this also do not hit on > some of the most important factors such as DoS mitigation and legacy scri= pt > attack surface reduction. > > Peter Todd > > NACK ... > > PortlandHODL: You NACK'd for the same reasons that I stated in my OP, > without including any additional context or reasoning. > > jeremy > > I think that this type of rule is OK if we do it as a "sunsetting" > restriction -- e.g. a soft fork active for the next N blocks (N =3D e.g. = 2 > years, 5 years, 10 years). > > If action is taken, this is the most reasonable approach. Alleviating > confiscatory concerns through deferral. > > > 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 > myself feel that overall our understanding of Bitcoin transaction > programming possibilities is still early. If you don't like this example= , > I can give you others (probably). > > Agreed and this also falls into the reasoning for deciding to utilize > point 1 in your response. My thoughts on this would be along the lines of > proof of publication as this change only has the effect of stripping away > the executable 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 published in chunked segments using outpoints. > > 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. > > This sums up the majority of future usecase concern > > 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) > > Could this not be done as segments in multiple outpoints using a > coordination outpoint? I fail to see why publication proof must be in a > single chunk. This does though however bring another alternative to mind, > just making these outpoints unspendable but not invalidate the block > through inclusion... > > > 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 > > Correct, this was never meant to resolve this issue. > > Luke Dashjr: > > If we're going this route, we should just close all the gaps for the > immediate future: > > To put it nicely, this is completely beyond the scope of what is being > proposed. > > 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. > > Completely off topic and irrelevant > > Greg Tonoski: > > Limiting the maximum size of the scriptPubKey of a transaction to 67 > bytes. > > 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 t= he > increased scope, any approach I take will only be related to the > ScriptPubkey > > Keagan McClelland: > > Hard NACK on capping the witness size as that would effectively ban > large scripts even in the P2SH wrapper which undermines Bitcoin's ability > to be an effectively programmable money. > > This has nothing to do with the witness size or even the P2SH wrapper > > Casey Rodarmor: > > I think that "Bitcoin could need it in the future?" might be a good > enough > reason not to do this. > > > 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 > recovery > 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. > > Would the ability to publish the data alone be enough? Example make the > output unspendable but allow for the existence of the bytes to be covered > through the signature? > > > Antoine Poinsot: > > Limiting the size of created scriptPubKeys is not a sufficient > mitigation 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 > checks. 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 with the current (n) limit included per input. > > > 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'Connor. > Limiting the size of > scriptPubKeys would in this regard be moving in the opposite direction. > > 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 o= f > redemption of TXs that break that rule and the input set to do this alrea= dy > exists on-chain no need to even wonder about the whole presigned. > bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 > > Please let me know if I am incorrect on any of this. > > > Furthermore, it's always possible to get the biggest bang for our buck > in a first step > > Agreed on bang for the buck regarding DoS. > > 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 > incomplete or incorrect, This is just my in the moment response. > > Antoine Riard: > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more in > favor of prioritizing > a timewarp fix and limiting dosy spends by old redeem scripts > > The idea of congestion control is interesting, but this solution should > significantly reduce the total DoS severity of known vectors. > > On Saturday, October 18, 2025 at 2:25:18=E2=80=AFAM UTC-7 Greg Maxwell wr= ote: > >> 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 mining code generating higher profits is a pro >> centralization factor. >> >> In terms of effectiveness the "spam" will just make itself >> indistinguishable from the most common transaction traffic from the >> perspective of such metrics-- and might well drive up "spam" levels >> because the higher embedding cost may make some of them use more >> transactions. The competition for these buckets by other traffic could >> make it effectively a block size reduction even against very boring >> ordinary transactions. ... which is probably not what most people want. >> >> 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 >> cost-- so anyone still embedding data in bitcoin *really* want to be the= re >> for 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 fees are what create the scarcity needed for their seigniorage. >> >> But yeah I think your comments on priorities are correct. >> >> >> On Sat, Oct 18, 2025 at 1:20=E2=80=AFAM Antoine Riard >> wrote: >> >>> Hi list, >>> >>> Thanks to the annex covered by the signature, I don't see 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 flexibly accomodate a wide range of things. >>> >>> I believe there is one thing that has not been proposed to limit >>> unpredictable utterance >>> of spams on the blockchain, namely congestion control of categories of >>> outputs (e.g "fat" >>> scriptpubkeys). Let's say P a block period, T a type of scriptpubkey an= d >>> L a limiting >>> threshold for the number of T occurences during the period P. Beyond th= e >>> L threshold, any >>> additional T scriptpubkey is making the block invalid. Or alternatively= , >>> any additional >>> T generating / 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 the context of >>> lightning to solve mass >>> closure, where channels out-priced 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 block space spamming transaction. >>> Qualitative spam it's another >>> question, for anyone who has ever read shannon's theory of communicatio= n >>> 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]. >>> >>> Anyway, in the sleeping pond of consensus fixes fishes, I'm more in >>> favor 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. >>> >>> [0] If you have a soul of logician, it would be an interesting >>> demonstration to 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: >>> 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e4999 >>> Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poinsot a = =C3=A9crit : >>> >>>> Hi, >>>> >>>> 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 create= d >>>> scriptPubKeys is not a >>>> sufficient mitigation on its own, and has a non-trivial confiscatory >>>> surface. >>>> >>>> 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'Connor. >>>> 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 >>>> discussed, in forms that would >>>> mitigate the confiscatory surface, to adopt in addition to (what >>>> eventually 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 mak= e >>>> 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 >>>> *unevenly* stalling the network >>>> for dozens of minutes, and a revenue-maximizing miner from regularly >>>> 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. >>>> >>>> Furthermore, it's always possible to get the biggest bang for our buck >>>> 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 the >>>> reasons stated here: >>>> >>>> https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit= /1732/8. >>>> I wouldn't hold my >>>> breath on such a "cleanup v2", but it may be useful to have it >>>> documented somewhere. >>>> >>>> I'm trying to not go into much details regarding which mitigations wer= e >>>> considered in designing >>>> BIP54, because they are tightly related to the design of various DoS >>>> blocks. But i'm always happy to >>>> rehash the decisions made there and (re-)consider alternative >>>> approaches on the semi-private Delving >>>> thread [0] dedicated to this purpose. Feel free to ping me to get >>>> access 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: >>>> >>>> > >>>> > >>>> > 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 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%40consol= e. >>>> >>>> >>> -- >>> 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/5135a031-a94e-49b9-ab31-a1= eb48875ff2n%40googlegroups.com >>> >>> . >>> >> -- > 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/bitcoindev/78475572-3e52-44e4-8116-8f1a= 917995a4n%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/= CALiT-ZpYav87WPn-hrFEcSrvLet95_B%3DMPzqi6kk%3D_nSnQj1VQ%40mail.gmail.com. --00000000000097427b064171b4d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi portlandhold,

>=C2=A0PortlandHODL= : I reject this completely as this would remove the UTXOset omission for th= e scriptPubkey

Your proposed solution would affect= the UTXO set negatively if someone is really motivated to use scriptpubkey= for arbitrary data. They will use multiple outputs as people do with [DNS = records][0].

> and encourage miners to subvert = the OP_RETURN restriction and instead just use another op_code
What would motivate users to follow this approach, considering= that storing data in the witness is cheaper?


/dev/fd0
floppy disk gu= y


On Sat, Oct 18, 2025 at 6:45=E2= =80=AFPM PortlandHODL <admin@qrsnap.i= o> wrote:
Hey,

First, thank you to everyone who responded, and please contin= ue to do so. There were many thought provoking responses and this did shift= my perspective quite a bit from the original post, which in of itself was = the goal to a degree.

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.

Tl;dr (Portlands Perspective)
=C2=A0- C= onfiscation is a problem because of presigned transactions
=C2=A0- DoS m= itigation could also occur through marking UTXOs as unspendable if > 520= bytes, this would preserve the proof of publication.
=C2=A0- Timeout / = Sunset logic is compelling
=C2=A0- The (n) value of acceptable needed by= tes is contentious with the lower suggested limit being 67
=C2=A0- Conge= stion control is worth a look?

Next Step:
=C2=A0- Deeper discussi= on at the individual level: Antoine Poinsot and GCC overlap?
=C2=A0- Wr= ite an implementation.
=C2=A0- Decide to pursue BIP

Responses
=
Andrew Poelstra:
> There is a risk of confiscation of coins whic= h have pre-signed but
> unpublished transactions spending them to new= outputs with large
> scriptPubKeys. Due to long-standing standardnes= s rules, and the presence
> of P2SH (and now P2WSH) for well over a d= ecade, I'm skeptical that any
> such transactions exist.

P= ortlandHODL: 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 re= cursively iterating over a chain there is a chance that a presigned breaks = this rule. Every idea I have had from block redemption limits on prevouts s= eems to just be a coverage issue where you can make the confiscation less l= ikely but not completely mitigated.

Second, there are already TXs th= at effectively have been confiscated at the policy level (P2SH Cleanstack v= iolation) where the user can not find any miner with a policy to accept the= se into their mempool. (3 years)

/dev /fd0
> =C2=A0so it would= be great if this was restricted to OP_RETURN

PortlandHODL: I reject= this completely as this would remove the UTXOset omission for the scriptPu= bkey and encourage miners to subvert the OP_RETURN restriction and instead = just use another op_code, this also do not hit on some of the most importan= t factors such as DoS mitigation and legacy script attack surface reduction= .

Peter Todd
> NACK ...

PortlandHODL: You NACK'd fo= r the same reasons that I stated in my OP, without including any additional= context or reasoning.

jeremy
> I think that this type of rul= e is OK if we do it as a "sunsetting" restriction -- e.g. a soft = fork active for the next N blocks (N =3D e.g. 2 years, 5 years, 10 years).<= br>
If action is taken, this is the most reasonable approach. Alleviatin= g confiscatory concerns through deferral.

> You can argue agains= t this example probably, but it is worth considering that absence of eviden= ce of use is not evidence of absence of use and I myself feel that overall = our understanding of Bitcoin transaction programming possibilities is still= early.=C2=A0 If you don't like this example, I can give you others (pr= obably).

Agreed and this also falls into the reasoning for deciding = to utilize point 1 in your response. My thoughts on this would be along the= lines of proof of publication as this change only has the effect of stripp= ing away the executable 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 published in chunked segments using outpoints.

Andrew Poel= stra:
> Aside from proof-of-publication (i.e. data storage directly i= n the UTXO
> set) there is no usage of script which can't be equa= lly (or better)
> accomplished by using a Segwit v0 or Taproot script= .

This sums up the majority of future usecase concern

Anthony= Towns:
> (If you restricted the change to only applying to scripts t= hat used
non-push operators, that would probably still provide upgrade f= lexibility
while also preventing potential script abuses. But it wouldn&= #39;t do anything
to prevent publishing data)

Could this not be d= one as segments in multiple outpoints using a coordination outpoint? I fail= to see why publication proof must be in a single chunk. This does though h= owever bring another alternative to mind, just making these outpoints unspe= ndable but not invalidate the block through inclusion...

> As fa= r as the "but contiguous data will be regulated more strictly"argument goes; I don't think "your honour, my offensive content h= as
strings of 4d0802 every 520 bytes

Correct, this was never mean= t to resolve this issue.

Luke Dashjr:
> If we're going thi= s route, we should just close all the gaps for the immediate future:
To put it nicely, this is completely beyond the scope of what is being pro= posed.

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.

Complete= ly off topic and irrelevant

Greg Tonoski:
> Limiting the maxim= um size of the scriptPubKey of a transaction to 67 bytes.

This leave= no room to deal with broken hashing algorithms and very little future upgr= adability for hooks. The rest of these points should be merged with Lukes r= esponse and either hijack my thread or start a new one with the increased s= cope, any approach I take will only be related to the ScriptPubkey

K= eagan McClelland:
> Hard NACK on capping the witness size as that wou= ld effectively ban large scripts even in the P2SH wrapper which undermines = Bitcoin's ability to be an effectively programmable money.

This = has nothing to do with the witness size or even the P2SH wrapper

Cas= ey Rodarmor:
> I think that "Bitcoin could need it in the future= ?" might be a good enough
reason not to do this.

> Script= pubkeys are the only variable-length transaction fields which can be
co= vered by input signatures, which might make them useful for future soft
= forks. I can imagine confidential asset schemes or post-quantum coin recove= ry
schemes requiring large proofs in the outputs, where the validity of = the proof
determined whether or not the transaction is valid, and thus r= equire the
proofs to be in the outputs, and not just a hash commitment.<= br>
Would the ability to publish the data alone be enough? Example make = the output unspendable but allow for the existence of the bytes to be cover= ed through the signature?


Antoine Poinsot:
> Limiting the = size of created scriptPubKeys is not a sufficient mitigation on its own
= I fail to see how this would not be sufficient? To DoS you need 2 things in= puts with ScriptPubkey redemptions + heavy op_codes that require unique che= cks. Example DUPing stack element again and again doesn't work. This th= en leads to the next part is you could get up to unique complex operations = with the current (n) limit included per input.

> One of the goal = of BIP54 is to address objections to Matt's earlier proposal, notably t= he (in my
opinion reasonable) confiscation concerns voiced by Russell O&= #39;Connor. Limiting the size of
scriptPubKeys would in this regard be m= oving in the opposite direction.

Some notes is I would actually go a= s 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 rul= e and the input set to do this already exists on-chain no need to even wond= er about the whole presigned. bb41a757f405890fb0f5856228e23b715702d714d59bf= 2b1feb70d8b2b4e3e08

Please let me know if I am incorrect on any of t= his.

> Furthermore, it's always possible to get the biggest b= ang for our buck in a first step

Agreed on bang for the buck regard= ing DoS.

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 co= uld be incomplete or incorrect, This is just my in the moment response.
=
Antoine Riard:
> Anyway, in the sleeping pond of consensus fixes = fishes, I'm more in favor of prioritizing
a timewarp fix and limitin= g dosy spends by old redeem scripts

The idea of congestion control i= s interesting, but this solution should significantly reduce the total DoS = severity of known vectors.=C2=A0

On Saturday, October 18, 2025 at 2:25:18=E2= =80=AFAM UTC-7 Greg Maxwell wrote:
Limits on block construction that = cross transactions make it harder to accurately estimate fees and greatly c= omplicate optimal block construction--=C2=A0 the latter being important bec= ause smarter and more computer powered mining code generating higher profit= s is a pro centralization=C2=A0factor.

In terms of= effectiveness=C2=A0the "spam" will just make itself indistinguis= hable from the most common transaction traffic from the perspective of such= metrics--=C2=A0 and might well drive up "spam" levels because th= e higher embedding cost may make some of them use more transactions.=C2=A0 = The competition for these buckets by other traffic could make it effectivel= y a block size reduction even against very boring ordinary transactions.=C2= =A0 ... which is probably not what most people want.

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= cost-- so anyone still embedding data in bitcoin *really* want to be there= for some reason and aren't too fee sensitive=C2=A0or else they'd a= lready be using something else... some are even in favor of higher costs si= nce the high fees are what create the scarcity needed for their seigniorage= .

But yeah I think your comments on priorities are= correct.


On Sat, Oct = 18, 2025 at 1:20=E2=80=AFAM Antoine Riard <antoin...= @gmail.com> wrote:
Hi list,

Thanks to the an= nex covered by the signature, I don't see how the concern about limitin= g
the extensibility of bitcoin script with future (post-quantum) cryptog= raphic schemes.
Previous proposal of the annex were deliberately designe= d with variable-length fields
to flexibly accomodate a wide range of thi= ngs.

I believe there is one thing that has not been proposed to limi= t unpredictable utterance
of spams on the blockchain, namely congestion = control of categories of outputs (e.g "fat"
scriptpubkeys). Le= t'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= alternatively, any additional
T generating / 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 h= as been floated few times in the context of lightning to solve mass
clos= ure, where channels out-priced at current feerate would have their safety t= imelocks scale
ups.

No need anymore to come to social consensus o= n what is quantitative "spam" or not. The blockchain
would aut= omatically throttle out the block space spamming transaction. Qualitative s= pam it's another
question, for anyone who has ever read shannon'= s theory of communication 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].

Anyway, in the sleepin= g pond of consensus fixes fishes, I'm more in favor 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&= quot; consensus mitigations.

[0] If you have a soul of logician, it = would be an interesting demonstration to 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 ling= uistical issue.

Best,
Antoine
OTS hash: 6cb50fe36ca0ec5cb9a885= 17dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e4999
Le vendredi 17 octobre 2025 =C3=A0 19:= 45:44 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:
Hi,

This approach was discussed last year when evaluating the best way to m= itigate DoS blocks in terms
of gains compared to confiscatory surface. Limiting the size of created= scriptPubKeys is not a
sufficient mitigation on its own, and has a non-trivial confiscatory su= rface.

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 direction.

Various approaches of limiting the size of spent scriptPubKeys were dis= cussed, in forms that would
mitigate the confiscatory surface, to adopt in addition to (what eventu= ally became) the BIP54 sigops
limit. However i decided against including this additional measure in B= IP54 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 mor= e mitigations. The BIP54
limit on its own prevents an externally-motivated attacker from *unev= enly* stalling the network
for dozens of minutes, and a revenue-maximizing miner from regularly = stalling its competitions
for dozens of seconds, at a minimized cost in confiscatory surface. A= dditional mitigations reduce
the worst case validation time by a smaller factor at a higher cost i= n terms of confiscatory
surface. It "feels right" to further reduce those numbers, = but it's less clear what the tangible
gains would be.

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 floa= ted 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 the re= asons stated here:
https://delvingbitcoi= n.org/t/non-confiscatory-transaction-weight-limit/1732/8. I wouldn'= 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.or= g/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%40con= sole.

--
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 bitcoindev+...@googlegroups.com.
To view this discussion visit htt= ps://groups.google.com/d/msgid/bitcoindev/5135a031-a94e-49b9-ab31-a1eb48875= ff2n%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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/78475572-3e52-44e4-8116-8f1a917995a4n%40googlegrou= ps.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/bitcoindev/CALiT-ZpYav87WPn-hrFEcSrvLet95_B%3DMPzqi6kk%3D_nSnQj1VQ%= 40mail.gmail.com.
--00000000000097427b064171b4d3--