From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 08 Oct 2025 09:24:50 -0700 Received: from mail-yw1-f191.google.com ([209.85.128.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v6Wy9-0007LN-Na for bitcoindev@gnusha.org; Wed, 08 Oct 2025 09:24:50 -0700 Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-738a7fc9901sf948977b3.0 for ; Wed, 08 Oct 2025 09:24:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759940683; cv=pass; d=google.com; s=arc-20240605; b=VU+bZ0FafrGkglOkSxNsaeEajoJXgnLfu3JdGJw3SXvDjoxiyswNpc/atp2j55FcA5 Q4lONhC/THWHkcLoG3vL+xdwNsomtKjcIg408TT+nLYbUw1L0PqgZDeacSH1O3UdDYLH KTyyhLQKwR1zAlV+/36PZeS73Q7IrrBajpNuiO/d4+KXrHqSOtCtDqz9zgFTX1Z8i+dh 2aX8JcoUbyjJ18BIHbNy+QsAvwFXhxyV3O8HaFS4wixcgsxgbHRfqgl8GEM6T5IP6A37 KVGcm67CD2uHdvt6EdoQGi3xHOtYTkokDe6+MaP7Wp4KUZm4IlJA6ICtuVYsM54tZUEB 8qaA== 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=jd82tnsTkA2o/X4ILK3bd9lw+JiiJz4ZdA95zEEKntc=; fh=MjMRKS01sPbXkBdR9XmecONpQsPqiT+mxiqOIqKqp2Q=; b=g1nJM/jRDrR2xCogdtizcq0S5rAWp/L/rcb88iY0rz9nezldDB1a9xIhIRuhiXDfHm x3Vcvde7F8qgOu1VDzzpHN5tSAGUvewwO6RQBI9kf+R8x+otnz7eQSgiMH1F8bOa/14f GwBdZctcbxDG7WdRe20KKB4cbY6cEhzQ78UrgKNaYmNIiVXZWpK7TAK+JBapJkd2k0kn ewX12XsY7VlYj50p0yl7rUTV6mV98q+6Dxdm/CIRN6Y2ptza+MVnH6LP3WMBY4BgZqtU OpBysYlvOHZ0QXswaggqZtCXdbcGHaLt0o9hyvg9jH1ZrU12VcPiII3EqAuWXWqTKtzs M/PA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Mh8LD5Uo; spf=pass (google.com: domain of gregtonoski@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=gregtonoski@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=1759940683; x=1760545483; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=jd82tnsTkA2o/X4ILK3bd9lw+JiiJz4ZdA95zEEKntc=; b=kJrHjfHGBYNIN6B3J8uxj++PNglSiRxm1uuEi7kaW2NXp1B6tE2F+rZ9/lvHhnrf2v CNWb2TNVdqzrOZkILfMOqh/sMbbAsqNw6kKZQ+ApZgW+uU5iGWN3LWKt9OPuOBuEQKzt 0CZEF8umZwAnEt7HK5MBy8NsommswxmMWueFO/AYpVSkd/tEeqStXJ6mgws4uYtqz82Q cS6wYDqKIsfefAoBB4SPIGt4QX+8rTv3bzOnDyxh/yIAXbNt3Y2UYbvRjeboCefCBv3t 8m5GMvRpW1elbaybHdXHdqIqAPK98+vX4snWJiJhh9/ybTqppI038bIHiCRXlmEBd4Su YMUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759940683; x=1760545483; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jd82tnsTkA2o/X4ILK3bd9lw+JiiJz4ZdA95zEEKntc=; b=G7bgOsvjE2vz7ZcBP2Iqk/2m04tPN8jwzv45CUdnNg4tBgs1Kgi72sho9FVZJYWmwr NICnwo2eMFainmBa9wRQ5ZbWS1hq37ZxhvyYcn25TEDOpubAr5Uo/3P2qa2Bjf8t1JwP VMkWC9cBjq3UOF0YdtgKlj+SSR4Tx7lOUdknageZ1OJURCVQCoS9fKfJhU4dNog8UkL5 BER0nMqATKKK7P6HsbEdujEfIEjdXD0dJZMNHstI1iqL8wuZujkqI45QwuCUrqDWRwWm tUMfDzFsXBtJwsGFk5dyFZF6o0so/mld5jw/qgfx3ZTS7B1Omxd151iDGWpnxzO5EhNh 4w8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759940683; x=1760545483; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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=jd82tnsTkA2o/X4ILK3bd9lw+JiiJz4ZdA95zEEKntc=; b=qOLjWg27kd6nu1Mj9dBd+RwCQrO9bX/3golDIq3q65BrxChFKl+4Zggujfgr7MW4BM hjB1LXE9ro8XNkqzSxzqOxKMBszlUE/rD2ZQ8/DI4pIV1idN6FaxIJ+QMibRFhINYcXy FPzssWjJ76arak6W26kn/H4CthWlw2tFwuIUnC7uzeFMzIxSmpniHQ/eQlPXvsdeCko/ Q1rLICKtZU9ZlzdMCi2+c3NpVBEYNKUloaFoDTkwtQmlkODhZ0ObLi4sWc6DYxdTGM3q JNy3GEoiJbcoF8K3uZySK5agGWKQYzZAqsQPJ27i07I1Bh3nKENlazdGxs0YYjAUTUCl +TEw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUpjnzTSOc+JQhGsPPQt5fZyGnDbQX2KvnmBBo46Px5PB1v58BQ5yqLriErUmr+kZjO8YJ7KcYwWuGX@gnusha.org X-Gm-Message-State: AOJu0Yx4cUBzI192SvBv7qhQYOYOX+9mwzyoxU/uk/rvL9dY23BwtJYr NYCFVl2zMFbfhgzkAx5hQwAZK2WI2XZZZirRtNSrGyrKoOP5L7Xr6E6i X-Google-Smtp-Source: AGHT+IFgwC/qYmO1kCcqgA6NvmlWC3/h+EZNKuIbTbffifYcnTo7jKj7CYkZ9HmJRvsryxrYsfmfIA== X-Received: by 2002:a53:c591:0:b0:635:4ecc:fc23 with SMTP id 956f58d0204a3-63ccb957275mr3026507d50.43.1759940683338; Wed, 08 Oct 2025 09:24:43 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6+VooLMuhvtpNVLZJI4Zc+2kZlvsKqEQUNx5pfiKyXUg==" Received: by 2002:a05:690e:1547:10b0:5f3:b863:1e52 with SMTP id 956f58d0204a3-63cd96b29bfls56217d50.0.-pod-prod-03-us; Wed, 08 Oct 2025 09:24:38 -0700 (PDT) X-Received: by 2002:a05:690c:3505:b0:773:d1a:83d2 with SMTP id 00721157ae682-780e167ed94mr54576367b3.23.1759940678448; Wed, 08 Oct 2025 09:24:38 -0700 (PDT) Received: by 2002:a05:6808:4781:b0:43d:2644:97ea with SMTP id 5614622812f47-4417b76329fmsb6e; Wed, 8 Oct 2025 08:04:08 -0700 (PDT) X-Received: by 2002:a05:6808:188a:b0:43f:9b69:90b7 with SMTP id 5614622812f47-4417b3b216amr1820401b6e.32.1759935847217; Wed, 08 Oct 2025 08:04:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759935847; cv=none; d=google.com; s=arc-20240605; b=b3iO7hGyUdsNAkvbs5Va+F82jgViiqtwSCAz23p9sN2bE6bUGWgvRnq5IMcyH/q+Ry kOslNtr51DZZSVQtpN6Aqxlsmxuy/LemkYM7gKA3rRRB5nA+Vxl6co59lpk/qoDZ2rty h6VmT3lMKoesU/G6ZIzNxmIpkBqzx/4S3efLwnoPB+wXt8+p0WBoZmC2+MB3tO40xbCh +EiY8K1eI4KBy9AatA8CVpvMdp+DIMbI8nGKsxpApIwnU4RooizkaBm2cyL1IxcZeo4s tV6KWzG+9YUjx+t7BSDGIczu9gQrm00AT6upv0keCfAIXNTUowreIf1BB4k4M2K4M1OF M63Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=/gPWj+GcghmotBoaUQUx6qZ8FFfQHKwJol5xGArkMIc=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=MBgSJtDLEqQR1Iv+4CcL1/1wZjILrU2iITP46JjWcmd9H4XLBM6VWxuRKNtGeQDiCG RVjz9GJ1cS4gMkQdVpfmT+a332a4BGzAWkjink5PVqhOiIAHSBy4IpYT/jcardB0uA73 9Icy3enIyP3RRYZ2K1oHFPJ10k3dCPODKeRM71JYVICujRaJdUHKMOpyEDTbkL8TWuvF aLjYzl1s8uj3PXaYCLU1FzOiY6OQ4cUjbyPSRRGs9XgJ8P1EOWZynVN0E+Emn9MG45Da duaID5tceLuFfJyZgUwYlVfZQ1Adlj9dzJDcjw6PTeXtKRd4pgpDrU1YqpjX/SgqDpjs 3EkQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Mh8LD5Uo; spf=pass (google.com: domain of gregtonoski@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=gregtonoski@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com. [2607:f8b0:4864:20::1134]) by gmr-mx.google.com with ESMTPS id 8926c6da1cb9f-57b5e9e8bfdsi30540173.2.2025.10.08.08.04.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Oct 2025 08:04:06 -0700 (PDT) Received-SPF: pass (google.com: domain of gregtonoski@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) client-ip=2607:f8b0:4864:20::1134; Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-74f6974175dso89053407b3.3 for ; Wed, 08 Oct 2025 08:04:06 -0700 (PDT) X-Gm-Gg: ASbGncuKAy/pEvDWrvbgHMykcr0YAvSV9mYPEzFqHxb15KYrJHPqMBiza4dS8GVaztl eJBBChZMtsFodVru2FRzZjkmp1yTt2ZzcphI/wA3EO7ESXxA7cyvstcdvEWalDcv9tRGSrkM9J1 Y85/MvbhRSMum4/qqPLAAXKgy/T3BjPew9i9OLapGSZMRXClX3YDh+nJe9Dq85pHSP1oBYevPOf qXdue7bIZ+Y0wPtwFuTMrzmYr+XnhmSE/6ttm0TW5grdg2IUsUD4y1D+JKnWy0e+1vcOfRz9J1+ UPCPasIewVHseeEtBg== X-Received: by 2002:a53:ea84:0:b0:5f3:316d:1cf6 with SMTP id 956f58d0204a3-63ccb887d41mr2789693d50.21.1759935845335; Wed, 08 Oct 2025 08:04:05 -0700 (PDT) MIME-Version: 1.0 References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org> In-Reply-To: <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org> From: Greg Tonoski Date: Wed, 8 Oct 2025 17:03:54 +0200 X-Gm-Features: AS18NWDbzuW181OumVg3K_Q24KbuvibZ7p8YIhe6U_SsrJ9gsqdi47PeYGuE3iI Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000e38b290640a6fe0a" X-Original-Sender: gregtonoski@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Mh8LD5Uo; spf=pass (google.com: domain of gregtonoski@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=gregtonoski@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 (/) --000000000000e38b290640a6fe0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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/compatibility 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 (100 by policy.h). Any suggestions, anybody? --=20 Greg Tonoski On Fri, Oct 3, 2025 at 10:09=E2=80=AFPM Luke Dashjr wrote= : > 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 an= d > 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 fo= r > 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 invali= d. > > 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 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 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-378e= b2c0c701n%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/001afe1d-0282-4c68-8b1c-ebcc= 778f57b0%40dashjr.org > > . > --=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/= CAMHHROwJA5N%3DSfejF353oWFFsKVCtk5cpr9QkOv%2BZcqGDFz6oA%40mail.gmail.com. --000000000000e38b290640a6fe0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm for all the consensus proposals below and wou= ld further specify:
- limiting the maximum size of the scriptPubK= ey of a transaction to 67 bytes (to keep supporting P2PK and avoid impactin= g usability/compatibility of old, deprecated software and risk of similar c= orner cases); good riddance to P2MS;
- limit the maximum size of = script data pushes to 73 bytes (for the same reason, i.e. keep supporting f= or P2PK input: signature with its encoding overhead; also P2PKH) "with= an exception for BIP16 redeem scripts [which may embed multiple public key= s for multisig]",
- rule out "OP_FALSE OP_IF" (CVE= -2023-50428),
- discontinue P2SPAM (the one that repurposed the m= nemonic OP_RETURN and was standardized in 2014, commit a79342479f577013f2fd2573fb32585d6f4981b3).

BTW I think we should also consider consensus-wise limit on the maximum s= ize 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 (100 by = policy.h). Any suggestions, anybody?

--=C2=A0
Greg Tonoski

On Fri, Oct 3, 2025 at 10:09=E2=80= =AFPM Luke Dashjr <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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAMHHROwJA5N%3DSfejF353oWFFsKVCtk5cpr9QkOv%2BZcqGDFz6oA%= 40mail.gmail.com.
--000000000000e38b290640a6fe0a--