Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.HEADmaster

1 files changed, 406 insertions, 0 deletions

diff --git a/b7/1350c5dfb119efeb92c5ee738b6c8225bf15b6 b/b7/1350c5dfb119efeb92c5ee738b6c8225bf15b6
new file mode 100644
index 000000000..06146e2bf
--- /dev/null
+++ b/b7/1350c5dfb119efeb92c5ee738b6c8225bf15b6
@@ -0,0 +1,406 @@
+Delivery-date: Fri, 03 Oct 2025 13:09:16 -0700
+Received: from mail-ot1-f56.google.com ([209.85.210.56])
+	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+	(Exim 4.94.2)
+	(envelope-from <bitcoindev+bncBDD7VM4YZ4NBBX62QDDQMGQEOM66IJA@googlegroups.com>)
+	id 1v4m5b-000181-J8
+	for bitcoindev@gnusha.org; Fri, 03 Oct 2025 13:09:16 -0700
+Received: by mail-ot1-f56.google.com with SMTP id 46e09a7af769-7b187d6f673sf772597a34.1
+        for <bitcoindev@gnusha.org>; Fri, 03 Oct 2025 13:09:15 -0700 (PDT)
+ARC-Seal: i=2; a=rsa-sha256; t=1759522149; cv=pass;
+        d=google.com; s=arc-20240605;
+        b=BoSD/7A4Otxmt60M5HO6P0QhMVLjFEioCb8c+d3WzhLYzRMtm09gDIa7CNJVtheTm5
+         oSZzDoSjZU4WwaC+Q4snoqZVRpc93Z4gcAKSO+EXBu3M3E34A6e+GV2mBZP683vaM1MP
+         Rk/6B3ud5lhTi+j9pLXatgvu2Jop3g3yvCrxGXGpb7LCmUi+xIsBY9E+38t9R+giIJ2l
+         AzB5+2GNb68rsofXOEqugfS+Y0w5xIFOyFle5zN/lmyB1qWtWz8j+kfRUq8eAWFVF15q
+         Ni0F1h2FRSDbHcj/NO0+TNhy0kD4v0EgH2JYueG9WSLxBVd2YbLkLv18s1w0bbQvz/hs
+         653A==
+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:in-reply-to:autocrypt:from
+         :content-language:references:to:subject:mime-version:date:message-id
+         :sender:dkim-signature;
+        bh=ivgfLhVfcGllS3sjypUm5+qr8sIy2wpviQTli/7KbZE=;
+        fh=yXPZ96WhQcpn5QbKR/PhSKRxi5c1Zg4jZCR9Y4dhL7E=;
+        b=UYCG0VVR9R1/DmDna51Oyjc8TReDs5a7POD9mCp/CjHN90zei0Xs4uFefRGMcjri67
+         mGmk7w7ECH6RnoXbRdIXSMiaQPndXFxydh2cdWaot43CJmraAUTSBc4Q3R2bEyx7eIdw
+         R0PCmhkmG82tDUcQRnTuFUDtcAtP33NW/pPnAtcvz1Xe9NGbCF63pdcNYkn948iuEPCA
+         6JkbrjpYVRsC+P7isD7alC1dCScGnp2D/y/lvQ6dGY4oHE28UXnY/cxV280Pq4m6pF/H
+         eRN7QAKSzACiclL0jFWZx+sSn+p2nFNiw+BhSuJv8slC7brzektve6pC1uHEOqQ1ONmA
+         bnlA==;
+        darn=gnusha.org
+ARC-Authentication-Results: i=2; gmr-mx.google.com;
+       dkim=pass (test mode) header.i=@dashjr.org header.s=zinan header.b="kaGE/EE3";
+       spf=pass (google.com: domain of luke@dashjr.org designates 2001:470:88ff:2f::1 as permitted sender) smtp.mailfrom=luke@dashjr.org;
+       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=dashjr.org
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+        d=googlegroups.com; s=20230601; t=1759522149; x=1760126949; 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:in-reply-to:autocrypt:from:content-language
+         :references:to:subject:mime-version:date:message-id:sender:from:to
+         :cc:subject:date:message-id:reply-to;
+        bh=ivgfLhVfcGllS3sjypUm5+qr8sIy2wpviQTli/7KbZE=;
+        b=JO1t0qfwFpTFyPAv1phUknaZcMl8aUpU7qyPVzhct8/5p+feCJyl9uecwx6GW0QXoG
+         fq40h5Wt6JZJxTDTrlv5VG9Oo0I9MwIQJ/DchiAMWJLuquzpUYAh5lDJGv6iGWQXK3es
+         phELThNROz1r2+IREc9fNFbgIHClxSl0bbuHJzlzYMcKNeCQRWboZG1c7aJKdedppXBe
+         hZrmHgGGcJtqeHn/GXeOrEC8F66ioATuQKlEiZmFmy6lsZKOELcKmFMc3u3V0qsHlcfp
+         NG5ZwaOmWjUFv4wcZ4p0OpXbY5++iG0XyCuXQ6XL37zQRvxqmrUyq5SfyljWqGUp9WPz
+         /10g==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+        d=1e100.net; s=20230601; t=1759522149; x=1760126949;
+        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
+         :list-id:mailing-list:precedence:x-original-authentication-results
+         :x-original-sender:in-reply-to:autocrypt:from:content-language
+         :references:to:subject:mime-version:date:message-id:x-beenthere
+         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
+         :reply-to;
+        bh=ivgfLhVfcGllS3sjypUm5+qr8sIy2wpviQTli/7KbZE=;
+        b=RJwWCfr4Z71SOI6FrsCtFnKTiYcfgBqJwI/6wsAVx5mX3iiE1QGEFAm5u6A0RgFtEu
+         +VCINQsgPenomsLOwveMa2vUv/ge3OFz6t/u4l1f7I0U6Fx/AjK2ePr9D3oRf9cmGDIH
+         pCjcw3phnmBLmdqYjdvmmp8m4d65uSaA+uGr95AYWVvoowtEY99vXPcCMpal05M05iBC
+         BWF40tQyRKudX6rZRscrJAdQ+E4vbbhyXQOYSxMkrW75hybvQYjz180R3LXwUMPcAS25
+         CAyn3gJV1RmcIoh/9qrGHgXa5WfkoqCPkSn1KBWSBvSZNhjpsjn9L+8Gr5bXNgrxkIPC
+         iMBw==
+Sender: bitcoindev@googlegroups.com
+X-Forwarded-Encrypted: i=2; AJvYcCW+CuIpbFCivQLJf9u8eL4s+R+tylHK7W0n6BApk/4FjIHHv+4kYZFx+vHOfxp1DgQzqXIng0Eejedj@gnusha.org
+X-Gm-Message-State: AOJu0YwWXYcTbB6uQilsj8BSl7iIJ1zpYz4fPPtkGSI0+sn5QmC2BFuF
+	uWI+2J8dfF3zZDdIAsX9pC5VpuQJbBNkj+kmaUXjbWBz1hPnMy0+4+n5
+X-Google-Smtp-Source: AGHT+IHicBGIzVKpX3qxfYZcVAtXttZfyZWp6aOQHl7QMczv3veXzsZOxC+gUP9Tx5IjRff2WbR2dg==
+X-Received: by 2002:a05:6830:6519:b0:7bc:f57b:7388 with SMTP id 46e09a7af769-7bf772cd87fmr2833899a34.31.1759522149436;
+        Fri, 03 Oct 2025 13:09:09 -0700 (PDT)
+X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd5eludXcTsfpWg2g4iQoKjQtPzZvqGoyX0n2DjfK9X9TA=="
+Received: by 2002:a05:6820:26a:b0:646:73a2:101d with SMTP id
+ 006d021491bc7-64e00dd0b90ls1376366eaf.1.-pod-prod-07-us; Fri, 03 Oct 2025
+ 13:09:02 -0700 (PDT)
+X-Received: by 2002:a05:6808:6f89:b0:43f:18a2:97ae with SMTP id 5614622812f47-43fc182d8b9mr2285832b6e.30.1759522142843;
+        Fri, 03 Oct 2025 13:09:02 -0700 (PDT)
+Received: by 2002:a05:6808:1d37:b0:43f:5b9f:a4a0 with SMTP id 5614622812f47-43fc04cc07cmsb6e;
+        Fri, 3 Oct 2025 13:02:56 -0700 (PDT)
+X-Received: by 2002:a05:6a00:4f89:b0:781:2582:822a with SMTP id d2e1a72fcca58-78c98d41dccmr5540689b3a.8.1759521774954;
+        Fri, 03 Oct 2025 13:02:54 -0700 (PDT)
+ARC-Seal: i=1; a=rsa-sha256; t=1759521774; cv=none;
+        d=google.com; s=arc-20240605;
+        b=kGF4MGHshA3FgDV14K38gELwGV/OKuXKJUUpDUkHyuYXgig3BvurjN6WJxv2BzcVXK
+         wLkTxPiepxFI1ccNXekE+407qxSRKIIJtbg4PxDDKG0HoSo5h8Cmlfsoj40e3Tt/3W61
+         D+bqqwvDdVSaCQ6xWr4a4ibJEOxYvQmR/eieiKYMVKi9O93apLu6/u3LMhZdcV+jaNJd
+         VBd3OoKOfifHlpcrQe/L23Hl6M4+nhd9LXEarn/1i6KI+0x0iUoConHPG1NxlXSpOBfN
+         dRnmECa8vcQvuDQ+uOHotCuzhgcPrXqWG8LS9KvRZhCXpXmQrgFBEWpbBIPhQOflHaPz
+         EIFw==
+ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
+        h=in-reply-to:autocrypt:from:content-language:references:to:subject
+         :mime-version:date:message-id:dkim-signature;
+        bh=MCCZNXBIbP0yeMAQxweqswVgBUL+oTQBGsn+1qF9FkM=;
+        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
+        b=Ri94tqag5FDsw9DFnYJnLbsrCSbJiwcJpRgs1Q6gKwWuY8gCd8T26D0VoSughVBc5X
+         9JNpOPfmtdcpgFUPdRiByYSKgg3i4vCHwSXTrfZGJP+RrIPJe2bWW0TAqaDh3+HT5BDp
+         MWK101ZHzGPelRrvdZ3ZCsZ5SoN+490MIPBjEwgFTwnG7meTCTKa/zWxr1BpYXWyVFXA
+         VWs6qpT83IIVFX0OEs29cGHkIVq/eNZFhbmyp4ga4JI2/50MhYybbuLTExVK/9XjwhRJ
+         ual8JXpV2iIP/PsAjMiemtQteHMIPEU5FuTApxRW1IjUAabUoGMp9mqgz6+gT6yi/k8k
+         fw4g==;
+        dara=google.com
+ARC-Authentication-Results: i=1; gmr-mx.google.com;
+       dkim=pass (test mode) header.i=@dashjr.org header.s=zinan header.b="kaGE/EE3";
+       spf=pass (google.com: domain of luke@dashjr.org designates 2001:470:88ff:2f::1 as permitted sender) smtp.mailfrom=luke@dashjr.org;
+       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=dashjr.org
+Received: from zinan.dashjr.org (zinan.dashjr.org. [2001:470:88ff:2f::1])
+        by gmr-mx.google.com with ESMTP id d2e1a72fcca58-78b0206703bsi312193b3a.4.2025.10.03.13.02.54
+        for <bitcoindev@googlegroups.com>;
+        Fri, 03 Oct 2025 13:02:54 -0700 (PDT)
+Received-SPF: pass (google.com: domain of luke@dashjr.org designates 2001:470:88ff:2f::1 as permitted sender) client-ip=2001:470:88ff:2f::1;
+Received: from [1.2.3.4] (redacted.redacted [1.2.3.4])
+	(Authenticated sender: mailrelay)
+	by zinan.dashjr.org (Postfix) with ESMTPSA id 78E3A38A016C
+	for <bitcoindev@googlegroups.com>; Fri,  3 Oct 2025 20:02:45 +0000 (UTC)
+X-Hashcash: 1:23:251003:bitcoindev@googlegroups.com::2c2s+GI8PFD1Ju6g:A3OQ
+Content-Type: multipart/alternative;
+ boundary="------------9USteuNhkKKHAem0TjcTNae0"
+Message-ID: <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org>
+Date: Fri, 3 Oct 2025 16:02:42 -0400
+MIME-Version: 1.0
+Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
+To: bitcoindev@googlegroups.com
+References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
+Content-Language: en-US, en-GB
+From: Luke Dashjr <luke@dashjr.org>
+Autocrypt: addr=luke@dashjr.org; keydata=
+ xjMEaFluDBYJKwYBBAHaRw8BAQdA8ciTLjjpcVVfd6BZLTGfceA0lWpJP52catbbacgToV3N
+ Nkx1a2UgRGFzaGpyIChPcmRpbmFyeSBjb21tdW5pY2F0aW9uKSA8bHVrZUBkYXNoanIub3Jn
+ PsKYBBMWCgBBFiEEX2gZzRn0MRDD65wKZ6lXXEKSsmwFAmhZbgwCGwMFCQHhM4AFCwkIBwIC
+ IgIGFQoJCAsCBBYCAwECHgcCF4AACgkQZ6lXXEKSsmwalwD3e5U8wZ627LZy3OGaga/H/EXe
+ WIqAAwNY8W3C+droyAEAq/JO0xw4EDapLcU2H5Ep2fn5cEpr3LUiRREiQuCJygXOOARoWW4M
+ EgorBgEEAZdVAQUBAQdARTl7PMQ4q8Oeq9nZNLC82YefoTeqaW1uuCKnVd0Iki8DAQgHwn4E
+ GBYKACYWIQRfaBnNGfQxEMPrnApnqVdcQpKybAUCaFluDAIbDAUJAeEzgAAKCRBnqVdcQpKy
+ bODeAP9+r1dX/Hwymn14laDxUP35Glh57T+750RGoz+mroHn/gEA6qKd0qxjJoxz8LUO6JPy
+ Lx27XfEefvsgUzMbFaiMuAo=
+In-Reply-To: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
+X-Original-Sender: luke@dashjr.org
+X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass (test
+ mode) header.i=@dashjr.org header.s=zinan header.b="kaGE/EE3";       spf=pass
+ (google.com: domain of luke@dashjr.org designates 2001:470:88ff:2f::1 as
+ permitted sender) smtp.mailfrom=luke@dashjr.org;       dmarc=pass (p=NONE
+ sp=NONE dis=NONE) header.from=dashjr.org
+Precedence: list
+Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
+List-ID: <bitcoindev.googlegroups.com>
+X-Google-Group-Id: 786775582512
+List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
+List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
+List-Archive: <https://groups.google.com/group/bitcoindev
+List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
+List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
+ <https://groups.google.com/group/bitcoindev/subscribe>
+X-Spam-Score: -0.7 (/)
+
+This is a multi-part message in MIME format.
+--------------9USteuNhkKKHAem0TjcTNae0
+Content-Type: text/plain; charset="UTF-8"; format=flowed
+Content-Transfer-Encoding: quoted-printable
+
+If we're going this route, we should just close all the gaps for the=20
+immediate future:
+
+- Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem=20
+terrible. UTXOs are a huge cost to nodes, we should always keep them as=20
+small as possible. Anything else can be hashed (if SHA256 is broken, we=20
+need a hardfork anyway).
+
+- Limit script data pushes to 256 bytes, with an exception for BIP16=20
+redeem scripts.
+
+- Make undefined witness/taproot versions invalid, including the annex=20
+and OP_SUCCESS*. To make any legitimate usage of them, we need a=20
+softfork anyway (see below about expiring this).
+
+- Limit taproot control block to 257 bytes (128 scripts max), or at=20
+least way less than it currently is. 340e36 scripts is completely=20
+unrealistic.
+
+- Make OP_IF invalid inside Tapscript. It should be unnecessary with=20
+taproot, and has only(?) seen abuse.
+
+We can do these all together in a temporary softfork that self-expires=20
+after a year or two. This would buy time to come up with longer-term=20
+solutions, and observe how it impacts the real world. Since it expires,=20
+other softforks making use of upgradable mechanisms can just wait it out=20
+for those mechanisms to become available again - therefore we basically=20
+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=20
+metric so the above limits could be exceeded, but at a higher=20
+weight-per-byte; perhaps weigh data 25% more per byte beyond the=20
+expected size. This could also be a temporary softfork, perhaps with a=20
+rolling window, so future softforks could be free to lower weights=20
+should they be needed.
+
+Another idea might be to increase the weight based on=20
+coin-days-destroyed/coin-age, so rapid churn has a higher feerate than=20
+occasional settlements. But this risks encouraging UTXO bloat, so needs=20
+careful consideration to proceed further.
+
+Happy to throw together a BIP and/or code if there's community support=20
+for this.
+
+Luke
+
+
+On 10/2/25 16:42, PortlandHODL wrote:
+> Proposing: Softfork to after (n) block height; the creation of=20
+> outpoints with greater than 520 bytes in the ScriptPubkey would be=20
+> consensus invalid.
+>
+> This is my gathering of information per BIP 0002
+>
+> After doing some research into the number of outpoints that would have=20
+> violated the proposed rule there are exactly 169 outpoints. With only=20
+> 8 being non OP_RETURN. I think after 15 years and not having=20
+> discovered use for 'large' ScriptPubkeys; the reward for not=20
+> invalidating them at the consensus level is lower than the risk of=20
+> their abuse.
+>
+>   * *Reasons for
+>     *
+>       o Makes DoS blocks likely impossible to create that would have
+>         any sufficient negative impact on the network.
+>       o Leaves enough room for hooks long term
+>       o Would substantially reduce the divergence between consensus=C2=A0
+>         and relay policy
+>       o Incredibly little use onchain as evidenced above.
+>       o 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.
+>       o Would make it harder to use the ScriptPubkey as a 'large'
+>         datacarrier.
+>       o Possible UTXO set size bloat reduction.
+>
+>   * *Reasons Against *
+>       o Bitcoin could need it in the future? Quantum?
+>       o Users could just create more outpoints.
+>
+> Thoughts?
+>
+> source of onchain data=20
+> <https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubke=
+ys.csv>
+>
+> PortlandHODL
+>
+> --=20
+> You received this message because you are subscribed to the Google=20
+> Groups "Bitcoin Development Mailing List" group.
+> To unsubscribe from this group and stop receiving emails from it, send=20
+> an email to bitcoindev+unsubscribe@googlegroups.com.
+> To view this discussion visit=20
+> https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378e=
+b2c0c701n%40googlegroups.com=20
+> <https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378=
+eb2c0c701n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.
+
+--=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/=
+001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org.
+
+--------------9USteuNhkKKHAem0TjcTNae0
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<!DOCTYPE html>
+<html>
+  <head>
+    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
+">
+  </head>
+  <body>
+    <p>If we're going this route, we should just close all the gaps for
+      the immediate future:</p>
+    <p>- 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).</p>
+    <p>- Limit script data pushes to 256 bytes, with an exception for
+      BIP16 redeem scripts.</p>
+    <p>- 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).</p>
+    <p>- Limit taproot control block to 257 bytes (128 scripts max), or
+      at least way less than it currently is. 340e36 scripts is
+      completely unrealistic.</p>
+    <p>- Make OP_IF invalid inside Tapscript. It should be unnecessary
+      with taproot, and has only(?) seen abuse.</p>
+    <p>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.)</p>
+    <p>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.</p>
+    <p>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.</p>
+    <p>Happy to throw together a BIP and/or code if there's community
+      support for this.</p>
+    <p>Luke</p>
+    <p><br>
+    </p>
+    <div class=3D"moz-cite-prefix">On 10/2/25 16:42, PortlandHODL wrote:<br=
+>
+    </div>
+    <blockquote type=3D"cite"
+      cite=3D"mid:6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com">P=
+roposing:
+      Softfork to after (n) block height; the creation of outpoints with
+      greater than 520 bytes in the ScriptPubkey would be consensus
+      invalid. <br>
+      <br>
+      This is my gathering of information per BIP 0002<br>
+      <br>
+      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.=C2=A0<br>
+      <ul>
+        <li><b>Reasons for<br>
+          </b>
+          <ul>
+            <li>Makes DoS blocks likely impossible to create that would
+              have any sufficient negative impact on the network.</li>
+            <li>Leaves enough room for hooks long term<br>
+            </li>
+            <li>Would substantially reduce the divergence between
+              consensus=C2=A0 and relay policy</li>
+            <li>Incredibly little use onchain as evidenced above.</li>
+            <li>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.</li>
+            <li>Would make it harder to use the ScriptPubkey as a
+              'large' datacarrier.</li>
+            <li>Possible UTXO set size bloat reduction.<br>
+              <br>
+            </li>
+          </ul>
+        </li>
+        <li><b>Reasons Against=C2=A0</b>
+          <ul>
+            <li>Bitcoin could need it in the future? Quantum?<br>
+            </li>
+            <li>Users could just create more outpoints.</li>
+          </ul>
+        </li>
+      </ul>
+      Thoughts?<br>
+      <br>
+      <a
+href=3D"https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_=
+pubkeys.csv"
+        moz-do-not-send=3D"true">source of onchain data=C2=A0</a><br>
+      <br>
+      PortlandHODL<br>
+      <br>
+      -- <br>
+      You received this message because you are subscribed to the Google
+      Groups "Bitcoin Development Mailing List" group.<br>
+      To unsubscribe from this group and stop receiving emails from it,
+      send an email to <a
+        href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com"
+        moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">bitcoindev=
++unsubscribe@googlegroups.com</a>.<br>
+      To view this discussion visit <a
+href=3D"https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a77=
+1-378eb2c0c701n%40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfoot=
+er"
+        moz-do-not-send=3D"true">https://groups.google.com/d/msgid/bitcoind=
+ev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com</a>.<br>
+    </blockquote>
+  </body>
+</html>
+
+<p></p>
+
+-- <br />
+You received this message because you are subscribed to the Google Groups &=
+quot;Bitcoin Development Mailing List&quot; group.<br />
+To unsubscribe from this group and stop receiving emails from it, send an e=
+mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
+ev+unsubscribe@googlegroups.com</a>.<br />
+To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
+bitcoindev/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org?utm_medium=3De=
+mail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/001a=
+fe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org</a>.<br />
+
+--------------9USteuNhkKKHAem0TjcTNae0--
+