From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 08 Oct 2025 11:17:31 -0700 Received: from mail-yw1-f187.google.com ([209.85.128.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v6YjC-0003PN-23 for bitcoindev@gnusha.org; Wed, 08 Oct 2025 11:17:31 -0700 Received: by mail-yw1-f187.google.com with SMTP id 00721157ae682-746b28ff4c5sf2153987b3.3 for ; Wed, 08 Oct 2025 11:17:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759947444; cv=pass; d=google.com; s=arc-20240605; b=G9FiKdNbahY977PbCop6W+Qj0An3U04ZyixK/W7fVkilC+kxBaVm68q78aaxjPLVVo ngqIW+sUYbUk8NAD56T3Sv8gDAoDpgYV638kkm3peaWQmncgwdDHbaX+zorQpcuzUcbE AUv2AV3dDj4EcWKsDdNY9AT883I/Sw78yYpeQNsEaGXZzPYD3usUtJlrsjRYWYR1ZrUB Nmtu9UOBqHsUO51NvEXBSwS1rhfppJIIMyU/inwupHyfjg+wxzaerfx1KhlNxK2zfR1M aYa3eCgiRQaBmfW7bdaR7cOR3PEoC6PxSHT9DnnqcJeZI0r5zLfhKTIRDrzAjMoJKlQe tFRA== 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=swoKrD1Zx/NivziCey8ru7EYmuNaX65X6Sn0X2szNHU=; fh=98DPenRq2hyAhDaAsT5dDLqQq/rW4MOEZLuxRMveVqI=; b=Bzi56YgIekyPY5gUCLCrxLPvU2UiX+mXbeyGhPHUY5Hx9QUX6HU7bVBfi6kScdJRJG 7tydzndY+m6LF3QiQ6WlvTkVbavDkA5Ol17XSRdYgHVW8u4XY/Hl81eP2GagMiIYKum1 qesED6O7HUCprV1H3P0dQas2UScvHZ4sgmPKqh8TcZXPrOkj/XPkuWhgPMilaZzBqL5J cnj3AC27PyzVxqn5xbDf07oIP3qEl5U98rL/ratq7iOeeBT8nKG4uuByC2NtFym+z3HL xG1wP3DLF4dOYbdlCtk7IT/Vg/JWwHpGnnGnI+XbD8VM0FZT+CWVKqxaJ5dP08NuwXFG /tzQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="EEfIf9M/"; spf=pass (google.com: domain of keagan.mcclelland@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=keagan.mcclelland@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=1759947444; x=1760552244; 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=swoKrD1Zx/NivziCey8ru7EYmuNaX65X6Sn0X2szNHU=; b=XJT2YEeTsRN78M9fq5wcIszNIdmlAgJuViuhXi/MXHhUEUB7pXPOONxCpJbnTr1LIX YsIoe45jxzs6HvNWYeI/wCPDdngEsODLlJYYcqGaYdFug5Sdah1iKXmT8BI6JuTSME7g Z+/SWEwnHr/PaVHdKVPKXJ1Ip5d4O8hWrb7OlAerLhIQPuqth9Bj05bF1f0fi3/fOyqi 0VT9jvlbrJwemmRRAeEerVKN/PnKa+UsfTO7niIYo7zyKcbdnRvx76pdJErc7rG6bWsM vJ2HuZ6/bhAmbqdzGzVyJI8AzzK2JECMV+n7qio64LPd0+IRKVv6P+SCi2kIH2K7oT6H rCMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759947444; x=1760552244; 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=swoKrD1Zx/NivziCey8ru7EYmuNaX65X6Sn0X2szNHU=; b=m9LUCtnr9fZnWIUiuuED2nwYlrNtxjFipNcUdZqrRV1P+xYWxje1aQPt82LVoGaRyF kMHbaYAdk3qDwEcl0fkzzeaVF3jKqXRBt0/+Od8okfqKMx4T34yeWDV3ZJ3slVu1Q+1j yKj0dlmF70pnGxIuDwtPUE9G2uqL28/teG068mo02T8Eu5yvDAwxFPftp/PcbZuAb0mg rA46zqq2PKU7XjMQawDUQar+o5tsdjmj+6VupPT4VBFcQrFQtNQdwH/Za43RIQhdEJq0 xjm2Fl72r6s00j09UZ9lvfogwDvdSIyOTPdAVemF423Z3Q67lOm3nd+Rl8ox0motB6zx /RAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759947444; x=1760552244; 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=swoKrD1Zx/NivziCey8ru7EYmuNaX65X6Sn0X2szNHU=; b=kC3JMHSwPzpkPWCb2nG/es6mzZo+h/90wG3Jk26FzORzuuFGQuLix1xXK1pm2OELIW qHn/YmrdHd0qIxnU0IawtZehqTT+FxqoZhdKpid+0uSGQiIsK3iad1UtmxAjgJqGYLfP tM4oM7uAPCVhT2BbTXUQ8DHu+YgWrQyiXLXRRmTiBHkLRHWqKflMTkTnutRdgpBup769 c3gvJiwlO2B3xbJ2mI20b/+yS0BqpUV4ntohI1Arj2Ap25KPMEs7ZaZJ1FwNbElbvhNR lcZVhg6YwRWtbBtN3jG5kQRoDIhGAO3IdjDYtwysi4Bv/S6SN9nGQJFjAEvpC3Rh4DBb gWJQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVc2O+vy2pP7R6hbgMTAygl7VtQWLHfEBgDybSoWpgfp0L2Q6RNHj/szqxGy4UVrtTn9odDqqF7yki7@gnusha.org X-Gm-Message-State: AOJu0YzXyXA7d2/TGhhvo0vZBzEYAdtTTt7PByUSpjdXmvl8Q/h+atCj J9qXQSyqGhuBXdX63SqxlCUQGw+nYcVW+x1R6asYjBw6BjgxcxluDkZB X-Google-Smtp-Source: AGHT+IEAjFNW7K56WC72blRSicNwBcR2JQDz0ywkV273qwuNmI8cQnG2SOg2EkqyJ5BLTpMshLpMTQ== X-Received: by 2002:a05:690c:6085:b0:731:2d1e:c498 with SMTP id 00721157ae682-780e1639d7fmr45329357b3.5.1759947443691; Wed, 08 Oct 2025 11:17:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4pgZ4qAKZbZtZd9wsCp4E8rE8zACgHRMctOjFzEAgU4w==" Received: by 2002:a53:cdcb:0:b0:625:bcff:51d7 with SMTP id 956f58d0204a3-63cd97ffe5als153031d50.2.-pod-prod-07-us; Wed, 08 Oct 2025 11:17:16 -0700 (PDT) X-Received: by 2002:a05:690c:450a:b0:780:d230:3274 with SMTP id 00721157ae682-780e1767db1mr57937187b3.25.1759947436555; Wed, 08 Oct 2025 11:17:16 -0700 (PDT) Received: by 2002:a05:6808:8890:b0:438:241d:e72f with SMTP id 5614622812f47-4417b793ee0msb6e; Wed, 8 Oct 2025 11:15:21 -0700 (PDT) X-Received: by 2002:a05:6e02:178d:b0:42e:7ab6:ec89 with SMTP id e9e14a558f8ab-42f87413c4emr34250555ab.32.1759947321036; Wed, 08 Oct 2025 11:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759947321; cv=none; d=google.com; s=arc-20240605; b=BZLUEyp4k89RgPF+crLUhpBqvA3jqIXgSd1EyY1fWB4LmuGXG5W6C4ctqrmML9sy28 DWuxACOl2TGeRO28eAYq9Tb8bbY+lHwoBMjNFqBV8doAm828OIOST0Ya9VORAHpih/LN uoEJFdHZ1QQzsBDXDDabVJbtUEsxVPzaLwE4c3SVU1DgXRxR92Gbqyk3c3lBhtQMZjs4 Xs+2FliKvyHHSxmEcfsnqq9D0lk1heYKXXAKR5Cfj74S8j0+mwZFwuS6m+v4qBm37GvT y1mGxxrgpW6+MjARl4CxN2N1dghtYaAyQZAMDEtSBI64QjBoRKOgehIZ4OcYDSls92s0 2KIg== 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=l8AVJTS2HneZTbxMNUOM0NpY2KfIXbebeatXVX0qWZs=; fh=VDff1zHCc1waysePgEKe1+x5VBZk9AKWEJzTFb1pxLA=; b=KL64PXJpkdIIbHhrllHR0RFofOLarpN5MtunCI5kNjdVLQ7SQge6Ra4VIRD04S/7xe S2KbiVX8L8ODMcrzwi5Y8Z4TZ7jrSu8k2ejy4rkEUMdfZ/SgHWhURqQ2SqQoj3qEQjMp 0DjrYfwmlI4apr0ot+aBeLYZyoscwoYJimzuz4ZNekLO8OequUHpyIVpLl32/4SYUh8/ ODFaW5lTzFEYg1OaeO674bBbhcCo8/KweQzZwf1ktApFWNb1QM/g+uVWTKv/tFruQHbN VE2n0p227MWn2ihzoe3QUMRGh5vzuXBnUIZeOs6oQTzHYlT5FaXiwfgWlx7z8q3KuHIa 0OTg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="EEfIf9M/"; spf=pass (google.com: domain of keagan.mcclelland@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=keagan.mcclelland@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com. [2607:f8b0:4864:20::f2d]) by gmr-mx.google.com with ESMTPS id 8926c6da1cb9f-57b5eb62e00si66173.4.2025.10.08.11.15.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Oct 2025 11:15:21 -0700 (PDT) Received-SPF: pass (google.com: domain of keagan.mcclelland@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) client-ip=2607:f8b0:4864:20::f2d; Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-70ba7aa131fso2180046d6.2 for ; Wed, 08 Oct 2025 11:15:20 -0700 (PDT) X-Gm-Gg: ASbGncvUSAL5ZSxvaA5q8j0aqPM1ZKiaWrGEohpRzGQiRHv+rGnJc8qodtyjRw0tWK2 1QZCX7qtzn6YvtKy6P9h4bR1c3tDlGUw/p+WhoNApaKvFwKm66X4x8h6cXqVGo66lmPPEYXLYkS CqtiT3biO/qzmVV/0keC+px7DHsWFiqsx7lWiQJOQLtx76QPnxp1bnkl9Sp3qVkiUUidVAE1zj4 sYpS6uG2M7JMQ0A7RNOaszseOsBbAjVZgxRcaiTC0evxsP+MhSQ3L3mwc91PpRrWkBPaUwfPRa9 p4yGS/n0/x7uqlilfUY4qILfwZgDHtE2f5OTN4ufVLDhlVGoapCpYETUbiE/ X-Received: by 2002:ad4:5c62:0:b0:879:eb26:dafc with SMTP id 6a1803df08f44-87b2efdbb1dmr72307126d6.54.1759947319918; Wed, 08 Oct 2025 11:15:19 -0700 (PDT) MIME-Version: 1.0 References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org> In-Reply-To: From: Keagan McClelland Date: Wed, 8 Oct 2025 12:15:08 -0600 X-Gm-Features: AS18NWDv3k5uPDMePmwgnk9yc_tdMf5CUkeYpygE8NWOidTVEYeWZHgM7wbULaY Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: Greg Tonoski Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000d3d4370640a9aaf8" X-Original-Sender: keagan.mcclelland@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="EEfIf9M/"; spf=pass (google.com: domain of keagan.mcclelland@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=keagan.mcclelland@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 (/) --000000000000d3d4370640a9aaf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. The issue is that if you do that then you effectively make script unusable for complex scripting or anything related to ZKPs. At that point you may as well just remove script altogether and just make Bitcoin a key-only currency, which I think would be silly. I think making Bitcoin safely more programmable should be the goal, not hamstringing what can be done with script by capping the witness size. The "spam" (which I'll remind people is an incoherent idea in a leaderless system) is a symptom of the inability for a robust fee market to develop for block space. I am hesitant to limit the scriptPubKey all the way down to 67 bytes. Although it may be compelling to tighten it up as restrictively as possible, if we find a reason to increase it again, it either has to be done via a hard fork or via a significantly more complicated and subversive mechanism. I think a gradual tightening based off of concrete observations in the wild is a much more prudent approach. Keags On Wed, Oct 8, 2025 at 10:24=E2=80=AFAM Greg Tonoski wrote: > I'm for all the consensus proposals below and would further specify: > - limiting the maximum size of the scriptPubKey of a transaction to 67 > bytes (to keep supporting P2PK and avoid impacting usability/compatibilit= y > of old, deprecated software and risk of similar corner cases); good > riddance to P2MS; > - limit the maximum size of script data pushes to 73 bytes (for the same > reason, i.e. keep supporting for P2PK input: signature with its encoding > overhead; also P2PKH) "with an exception for BIP16 redeem scripts [which > may embed multiple public keys for multisig]", > - rule out "OP_FALSE OP_IF" (CVE-2023-50428), > - discontinue P2SPAM (the one that repurposed the mnemonic OP_RETURN and > was standardized in 2014, commit a79342479f577013f2fd2573fb32585d6f4981b3 > > ). > > BTW I think we should also consider consensus-wise limit on the maximum > size of the so-called Witness field (3600 bytes max. by policy.h) along > with max. size (80 bytes max. by policy.h) and max. count of its items (1= 00 > by policy.h). Any suggestions, anybody? > > -- > Greg Tonoski > > On Fri, Oct 3, 2025 at 10:09=E2=80=AFPM Luke Dashjr wro= te: > >> If we're going this route, we should just close all the gaps for the >> immediate future: >> >> - Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem >> terrible. UTXOs are a huge cost to nodes, we should always keep them as >> small as possible. Anything else can be hashed (if SHA256 is broken, we >> need a hardfork anyway). >> >> - Limit script data pushes to 256 bytes, with an exception for BIP16 >> redeem scripts. >> >> - Make undefined witness/taproot versions invalid, including the annex >> and OP_SUCCESS*. To make any legitimate usage of them, we need a softfor= k >> anyway (see below about expiring this). >> >> - Limit taproot control block to 257 bytes (128 scripts max), or at leas= t >> way less than it currently is. 340e36 scripts is completely unrealistic. >> >> - Make OP_IF invalid inside Tapscript. It should be unnecessary with >> taproot, and has only(?) seen abuse. >> >> We can do these all together in a temporary softfork that self-expires >> after a year or two. This would buy time to come up with longer-term >> solutions, and observe how it impacts the real world. Since it expires, >> other softforks making use of upgradable mechanisms can just wait it out >> for those mechanisms to become available again - therefore we basically >> lose nothing. (This is intended to buy us time, not as a permanent fix.) >> >> Alternatively, but much more complex, we could redesign the block weight >> metric so the above limits could be exceeded, but at a higher >> weight-per-byte; perhaps weigh data 25% more per byte beyond the expecte= d >> size. This could also be a temporary softfork, perhaps with a rolling >> window, so future softforks could be free to lower weights should they b= e >> needed. >> >> Another idea might be to increase the weight based on >> coin-days-destroyed/coin-age, so rapid churn has a higher feerate than >> occasional settlements. But this risks encouraging UTXO bloat, so needs >> careful consideration to proceed further. >> >> Happy to throw together a BIP and/or code if there's community support >> for this. >> >> Luke >> >> >> On 10/2/25 16:42, PortlandHODL wrote: >> >> Proposing: Softfork to after (n) block height; the creation of outpoints >> with greater than 520 bytes in the ScriptPubkey would be consensus inval= id. >> >> This is my gathering of information per BIP 0002 >> >> After doing some research into the number of outpoints that would have >> violated the proposed rule there are exactly 169 outpoints. With only 8 >> being non OP_RETURN. I think after 15 years and not having discovered us= e >> for 'large' ScriptPubkeys; the reward for not invalidating them at the >> consensus level is lower than the risk of their abuse. >> >> - >> *Reasons for * >> - Makes DoS blocks likely impossible to create that would have any >> sufficient negative impact on the network. >> - Leaves enough room for hooks long term >> - Would substantially reduce the divergence between consensus and >> relay policy >> - Incredibly little use onchain as evidenced above. >> - Could possibly reduce codebase complexity. Legacy Script is >> largely considered a mess though this isn't a complete disablement= it >> should reduce the total surface that is problematic. >> - Would make it harder to use the ScriptPubkey as a 'large' >> datacarrier. >> - Possible UTXO set size bloat reduction. >> >> - *Reasons Against * >> - Bitcoin could need it in the future? Quantum? >> - Users could just create more outpoints. >> >> Thoughts? >> >> source of onchain data >> >> >> PortlandHODL >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378= eb2c0c701n%40googlegroups.com >> >> . >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebc= c778f57b0%40dashjr.org >> >> . >> > -- > 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/CAMHHROwJA5N%3DSfejF353oWFFs= KVCtk5cpr9QkOv%2BZcqGDFz6oA%40mail.gmail.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/= CALeFGL0PDjtRt2rfbY4gTkoc%2B5oNQ0mn_obraE7PrtHuNYFpQw%40mail.gmail.com. --000000000000d3d4370640a9aaf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hard NACK on capping the witness size as that would effect= ively ban large scripts even in the P2SH wrapper which undermines Bitcoin&#= 39;s ability to be an effectively programmable money.

Th= e issue is that if you do that then you effectively make script unusable fo= r complex scripting or anything related to ZKPs. At that point you may as w= ell just remove script altogether=C2=A0and just make Bitcoin a key-only cur= rency, which I think would be silly. I think making Bitcoin safely more pro= grammable should be the goal, not hamstringing what can be done with script= by capping the witness size. The "spam" (which I'll remind p= eople is an incoherent idea in a leaderless system) is a symptom of the ina= bility for a robust fee market to develop for block space.

I am hesi= tant to limit the scriptPubKey all the way down to 67 bytes. Although it ma= y be compelling to tighten it up as restrictively as possible, if we find a= reason to increase it again, it either has to be done via a hard fork or v= ia a significantly more complicated and subversive mechanism. I think a gra= dual tightening based off of concrete observations in the wild is a much mo= re prudent approach.

Keags
<= br>
On Wed, Oct 8, 2025 at 10:24=E2=80=AFAM Greg Tonoski <greg.tonoski@gmail.com> wrot= e:
I'm for all the consensus proposals below and would further sp= ecify:
- limiting the maximum size of the scriptPubKey of a trans= action to 67 bytes (to keep supporting P2PK and avoid impacting usability/c= ompatibility of old, deprecated software and risk of similar corner cases);= good riddance to P2MS;
- limit the maximum size of script data p= ushes to 73 bytes (for the same reason, i.e. keep supporting for P2PK input= : signature with its encoding overhead; also P2PKH) "with an exception= for BIP16 redeem scripts [which may embed multiple public keys for multisi= g]",
- rule out "OP_FALSE OP_IF" (CVE-2023-50428),=
- discontinue P2SPAM (the one that repurposed the mnemonic OP_RE= TURN and was standardized in 2014, commit a79342479f577013f2fd2573fb32585d6f4981b3).

BTW I think we should also consider consensus-wise limit on the ma= ximum size of the so-called Witness field (3600 bytes max. by policy.h) alo= ng with max. size (80 bytes max. by policy.h) and max. count of its items (= 100 by policy.h). Any suggestions, anybody?

--=C2= =A0
Greg Tonoski

On Fri, Oct 3, 2025 at 10:09=E2=80=AFPM Luke Dash= jr <luke@dashjr.org= > wrote:
= =20 =20 =20

If we're going this route, we should just close all the gaps for the immediate future:

- Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem terrible. UTXOs are a huge cost to nodes, we should always keep them as small as possible. Anything else can be hashed (if SHA256 is broken, we need a hardfork anyway).

- Limit script data pushes to 256 bytes, with an exception for BIP16 redeem scripts.

- Make undefined witness/taproot versions invalid, including the annex and OP_SUCCESS*. To make any legitimate usage of them, we need a softfork anyway (see below about expiring this).

- Limit taproot control block to 257 bytes (128 scripts max), or at least way less than it currently is. 340e36 scripts is completely unrealistic.

- Make OP_IF invalid inside Tapscript. It should be unnecessary with taproot, and has only(?) seen abuse.

We can do these all together in a temporary softfork that self-expires after a year or two. This would buy time to come up with longer-term solutions, and observe how it impacts the real world. Since it expires, other softforks making use of upgradable mechanisms can just wait it out for those mechanisms to become available again - therefore we basically lose nothing. (This is intended to buy us time, not as a permanent fix.)

Alternatively, but much more complex, we could redesign the block weight metric so the above limits could be exceeded, but at a higher weight-per-byte; perhaps weigh data 25% more per byte beyond the expected size. This could also be a temporary softfork, perhaps with a rolling window, so future softforks could be free to lower weights should they be needed.

Another idea might be to increase the weight based on coin-days-destroyed/coin-age, so rapid churn has a higher feerate than occasional settlements. But this risks encouraging UTXO bloat, so needs careful consideration to proceed further.

Happy to throw together a BIP and/or code if there's community support for this.

Luke


On 10/2/25 16:42, PortlandHODL wrote:
Proposing: Softfork to after (n) block height; the creation of outpoints with greater than 520 bytes in the ScriptPubkey would be consensus invalid.

This is my gathering of information per BIP 0002

After doing some research into the number of outpoints that would have violated the proposed rule there are exactly 169 outpoints. With only 8 being non OP_RETURN. I think after 15 years and not having discovered use for 'large' ScriptPubkeys; the reward f= or not invalidating them at the consensus level is lower than the risk of their abuse.=C2=A0
  • Reasons for
    • Makes DoS blocks likely impossible to create that would have any sufficient negative impact on the network.
    • Leaves enough room for hooks long term
    • Would substantially reduce the divergence between consensus=C2=A0 and relay policy
    • Incredibly little use onchain as evidenced above.
    • Could possibly reduce codebase complexity. Legacy Script is largely considered a mess though this isn't a complete disablement it should reduce the total surface that is problematic.
    • Would make it harder to use the ScriptPubkey as a 'large' datacarrier.
    • Possible UTXO set size bloat reduction.

  • Reasons Against=C2=A0
    • Bitcoin could need it in the future? Quantum?
    • Users could just create more outpoints.
Thoughts?

source of onchain data=C2=A0
PortlandHODL

--
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/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40goog= legroups.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.google.com/d= /msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org.

--
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 http= s://groups.google.com/d/msgid/bitcoindev/CAMHHROwJA5N%3DSfejF353oWFFsKVCtk5= cpr9QkOv%2BZcqGDFz6oA%40mail.gmail.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/CALeFGL0PDjtRt2rfbY4gTkoc%2B5oNQ0mn_obraE7PrtHuNYFpQw%40ma= il.gmail.com.
--000000000000d3d4370640a9aaf8--