From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 05 Oct 2025 04:19:52 -0700 Received: from mail-ot1-f60.google.com ([209.85.210.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v5MmN-0002Ox-BZ for bitcoindev@gnusha.org; Sun, 05 Oct 2025 04:19:52 -0700 Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-79d89e83b1dsf4472509a34.2 for ; Sun, 05 Oct 2025 04:19:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759663185; cv=pass; d=google.com; s=arc-20240605; b=geGWV46uBcIbIoX7HHWdvIcf2lM9tAxWTBu/9pQQFHlUL5fvCPZyhpWpos0GEEvEOd Gctiv/ndzBLc11tCD6hmZgKItj+19eu0qgzvAv+KZ3ID0ShfkG+yEys/5NZDXqvu8Owp QGPU9V/zsRAViDtGKDbx647+MXZxW3j/A5vVh2D9MfqEgCmVPrOM2qEQNUKTBf3/viOi vASxHfOM75th54gDpq0MMcO/8oVSQ2g3YqKhXGUayApDYWCa6aydL4rv0Qjuvb+ZakdO /DUouQZweF4f5UAgzqZkcvox5E1G9KR6HO2yBeyNn7PBKrOGj2PSsO1OcsP1ug14LJNw zyOw== 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=6stLtWGceNgXq6YvYlQwz19wmWUGQEMvGMz+v5890+0=; fh=Y/9xjAoX1CcDtFq0vmx+Sinx2lnxbm/VWr1S1XF7/lU=; b=Pc+Vewm5diTUbIjEKbqdpFAh0Y7lh/PPmMORr6qXWcEH07EnWp7HohWdUwU3MrzypJ EuU1TBKKdkmd51RN5iizbppuP1bBVb7m/DZ2XQvLUCPsL55rPfLjXn9Or3ybfA7DUtmi GPiXINM/fImmlr7+9w1xJii8lPt59E6aTTXCnh9XDbuFHZvcnf38ThlQO+d5xNVhTjzC VU6C8Vj/ktT+7oh7WPyXpF75uhGSJlRUjatEZvRYV0y8mGtOrAPeWY6bNMuDR3a8C/9C Mgkn/k2Z7zIwK0eQu12taq2NIxAUr4Sf58+RAwve86N2n5dZgNzrcmxiy6opJ5jpcxnh esuQ==; 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=m8qzVhs1; spf=pass (google.com: domain of luke@dashjr.org designates 192.3.11.21 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=1759663185; x=1760267985; 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=6stLtWGceNgXq6YvYlQwz19wmWUGQEMvGMz+v5890+0=; b=dVDcNyJOHYruPLQBfSm5+KZi3FjwKb9zjcLIVmfB7cR2A/83u4vbTN9eNTdUkoBv08 fgOihzRlxBjKRTRQBDuZPsQ045Pch0bxROhrDm4BFMo6XnbsgxCo51wXIJHhOFB9lwqI NjwB+Ww7X+KA8O8lFHBZ+CZHWgX/X0dz6Ctx+yGdH8FjSTq9q7M/RiutllCk10mrvXOj rx+jQpB8DFUxBdmh02Rez25/ylIL1U7vOZKuQn4EezlVvPXcDlQSUyWyeLKdQGNA+W6k 0xyhaJde6tb1GG7gvAJXJcHmrKkaIIPCOGhW6ZqESDl6SIqWmHb/fWwlS8D07dnV5TR3 mTog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759663185; x=1760267985; 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=6stLtWGceNgXq6YvYlQwz19wmWUGQEMvGMz+v5890+0=; b=vIBD9vGMnSaSjJj/KirFJ9xHG7dmlnpXsjgtX9Uqs+alKtAQnCZ6NK1XYya9g6Z6oT X3nKwdFuFkdvDRxObZGZhE7oR99FIysPDQ24FlrKmcUyA2ps93qtnQavTLU0OA2zBCLK SqH9MvGfYHfNMhIsPYa9mAyXoCAB55F+zm3yV+XGnKdfNtVfL621KVIqn36zMPFldJOg rlmYKiqdHhqiqBJ7pGUNHvvGbJYdJsIVZSzM9ugCx+D+/bZwbJ05cuvK3ltqmKSUvbC5 C+/Si6EKO/aBv39Va3N5BrAvcmeTG/mKv5MhWjs6NtLasiVzk+ydqH3alBaoGQ5eag7f AVPw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVax48RUcSARl4m4v0ioz/s/t2S7QN0sigcGm9GOwwLHfPTLmLE70yGmVlLid98NwcqnN/ETeDf1HWk@gnusha.org X-Gm-Message-State: AOJu0YxTZDLiqUCsSPUKnDqHIkVVwQmNilPTNMkH28rJGrlo0FwkWXy2 wkm52MYYZtcjueS8SjILsrD7IUa+2dkS+KNVJdX/GKRcPVHRRaUH+fsP X-Google-Smtp-Source: AGHT+IHVV3KxHv6ebgv3i5qhiDGGoikial98OHttAtsyvhluMzHIA/M+L04EZ72/XpkjgdTNFXENFA== X-Received: by 2002:a05:6870:8185:b0:344:5201:15a4 with SMTP id 586e51a60fabf-3b0fd4ba2f8mr5450361fac.16.1759663185212; Sun, 05 Oct 2025 04:19:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4yjHB7CNP0Zk+SwoHW7yEbIo6p9v4TaTaL8DBZoV7Xag==" Received: by 2002:a05:6871:230e:b0:30b:d6e4:3de6 with SMTP id 586e51a60fabf-3ac01eb2b95ls1990867fac.2.-pod-prod-01-us; Sun, 05 Oct 2025 04:19:41 -0700 (PDT) X-Received: by 2002:a05:6808:1b24:b0:43f:5209:f803 with SMTP id 5614622812f47-43fc1860bc5mr4999530b6e.38.1759663180964; Sun, 05 Oct 2025 04:19:40 -0700 (PDT) Received: by 2002:a05:6808:4347:b0:3f9:f009:458e with SMTP id 5614622812f47-43fc073c74dmsb6e; Sun, 5 Oct 2025 03:59:31 -0700 (PDT) X-Received: by 2002:a05:6808:211a:b0:43d:2dc4:9d2e with SMTP id 5614622812f47-43fc176d980mr4408072b6e.6.1759661970738; Sun, 05 Oct 2025 03:59:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759661970; cv=none; d=google.com; s=arc-20240605; b=Sy8geBF1Y0XNg/rcsQHJNtQqajPEot+G/4svekEj+XWtr3nWDHt3aJEDJ3C2g01c3R zyJvWw0DwysWcB5klIrM++OtErH8dvmQngPWijDq+vH0oqtzR7Dgvlduk5au2WFA4QQL A8cucrScLJtjHFqjjiKSgfFJ2KasYrLaT95bUphqhvEDguvz2YDC7n9tBBDHbVfBy7nB ghZhN5yWFGsDRlJ1+ILWuVoDQweW5CewOfCAUUVLUioER/OXd11YToeCv9Qk90jleLb8 3wFpIbmuf7KfZH8I0bX2xdWX1EchlZdZTrILv0oO8Z28UBo10s129D0rSGz1j1vOwD5F frVQ== 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=7t9kQ6Rn5eqnJPqXpx3QcKfPs1/BzmFZj0A7bp3+qQs=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=dkzTzOM75MMXKoISB7Lom7CQKHghBVkimjevk/ecDPXj7szyAU5COuYZs/DgWjKh5q L8A/AO6+EIF1DZ2BZUbXYGSpfvt7GeF4MiuNFqA6I6CidFeAtJi0w53Jxwuv+s+2rqxo tdEoh9xxBOqrDIW/CFlPxUFZ3jy2yNN+qGAcZDmbQKp17wRIV6SsU6e0D1UrSK0LQoxI OIRcvsBwD2crKc/4aJCSdVv5g/kxx4N2A9u0bxhTw5ETmgIdX3o1LltlsYvsMYvnbiyz RS5dClO7h6V4orsMNQXVW4NX1CvwL2CaFLFePzY6THSlhRMBIa3YC/CdlMhF8C5H9i7/ R21A==; 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=m8qzVhs1; spf=pass (google.com: domain of luke@dashjr.org designates 192.3.11.21 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. [192.3.11.21]) by gmr-mx.google.com with ESMTP id 5614622812f47-43fc1930f63si167093b6e.3.2025.10.05.03.59.30 for ; Sun, 05 Oct 2025 03:59:30 -0700 (PDT) Received-SPF: pass (google.com: domain of luke@dashjr.org designates 192.3.11.21 as permitted sender) client-ip=192.3.11.21; Received: from [1.2.3.4] (redacted.redacted [1.2.3.4]) (Authenticated sender: mailrelay) by zinan.dashjr.org (Postfix) with ESMTPSA id CD79E38A0003 for ; Sun, 5 Oct 2025 10:59:18 +0000 (UTC) X-Hashcash: 1:23:251005:bitcoindev@googlegroups.com::b47WPs2REzddmc8H:TZ3J Content-Type: multipart/alternative; boundary="------------wlnJsRPH3oHSVXEpZ1G0upSs" Message-ID: <0585bba3-fb88-41d6-b86c-167774c14eb9@dashjr.org> Date: Sun, 5 Oct 2025 06:59:15 -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> <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org> <1e0f9843-0f08-4dea-b037-24df38bf8ed0n@googlegroups.com> Content-Language: en-US, en-GB From: Luke Dashjr 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: <1e0f9843-0f08-4dea-b037-24df38bf8ed0n@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=m8qzVhs1; spf=pass (google.com: domain of luke@dashjr.org designates 192.3.11.21 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------wlnJsRPH3oHSVXEpZ1G0upSs Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Yes, sorry if I was unclear. The temporary restriction of 257 B is=20 ultimately based on the size, which doesn't accommodate for that design=20 ideal. It's a tradeoff until a better solution is implemented. While it=20 might not be optimal in all cases to have 128 scripts, the fact remains=20 that size/depth _allows for it_. (And 128 depth is still unrealistic,=20 even if you don't like the script-count framing.) Luke On 10/4/25 19:12, jeremy wrote: > > - 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. > > > this is a misunderstanding of taptree's depth purpose, which is not to=20 > bound the number of elements directly. > > It's a bound on the huffman encoding to optimize for on-chain cost=20 > with many scripts and known likelihood of execution. > > So the right way to constrain taproot is by bounding the minimum=20 > probability of script execution. E.g., if it's one-in-4 billion chance=20 > of executing, then you'd need depth 32. > > 128 depth was chosen because if a branch is (2^128 -1)/2^128 unlikely=20 > to execute, then it's negligibly likely, the same order of probability=20 > as being able to e.g. brute force a key. > > On Friday, October 3, 2025 at 6:46:16=E2=80=AFPM UTC-4 /dev /fd0 wrote: > > Hi Luke, > > > We can do these all together in a temporary softfork that > self-expires after a year or two. > > That sounds reasonable and it could work if we can agree on the > specifics of this proposal. As Jeremy also mentioned in his email, > we could set up an auto-renewing restriction lasting 1=E2=80=932 year= s > with the option to remove it later if we decide we want to. > > /dev/fd0 > floppy disk guy > > On Sat, Oct 4, 2025 at 1:39=E2=80=AFAM 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 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 for not invalidating them at the >> consensus level is lower than the risk of 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 >> >> >> PortlandHODL >> >> --=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/6f6b570f-7f9d-40c0-= a771-378eb2c0c701n%40googlegroups.com >> . > --=20 > You received this message because you are subscribed to the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from > it, send an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8= b1c-ebcc778f57b0%40dashjr.org > . > > --=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/1e0f9843-0f08-4dea-b037-24df= 38bf8ed0n%40googlegroups.com=20 > . --=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/= 0585bba3-fb88-41d6-b86c-167774c14eb9%40dashjr.org. --------------wlnJsRPH3oHSVXEpZ1G0upSs Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yes, sorry if I was unclear. The temporary restriction of 257 B is ultimately based on the size, which doesn't accommodate for that design ideal. It's a tradeoff until a better solution is implemented. While it might not be optimal in all cases to have 128 scripts, the fact remains that size/depth _allows for it_. (And 128 depth is still unrealistic, even if you don't like the script-count framing.)

Luke

On 10/4/25 19:12, jeremy wrote:

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


this is a misunderstanding of taptree's depth purpose, which is not to bound the number of elements directly.

It's a bound on the huffman encoding to optimize for on-chain cost with many scripts and known likelihood of execution.

So the right way to constrain taproot is by bounding the minimum probability of script execution. E.g., if it's one-in-4 billion chance of executing, then you'd need depth 32.

128 depth was chosen because if a branch is (2^128 -1)/2^128 unlikely to execute, then it's negligibly likely, the same order of probability as being able to e.g. brute force a key.=C2=A0

On Friday, October 3, 2025 a= t 6:46:16=E2=80=AFPM UTC-4 /dev /fd0 wrote:
Hi Luke,

> We can do these all together in a temporary softfork that self-expires after a year or two.=C2=A0

That sounds reasonable and it could work if we can agree on the specifics of this proposal. As Jeremy also mentioned in his email, we could set up an auto-renewing restriction lasting 1=E2=80=932 years with the option to remo= ve it later if we decide we want to.

/dev/fd0
floppy disk guy

On Sat, Oct 4, 2025 at 1:39=E2=80=AFAM Luke Dashjr <lu...@dashjr.org<= /a>> 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 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 for 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+...@googlegroups.co= m.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%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+...@go= oglegroups.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 "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/bitcoind= ev/1e0f9843-0f08-4dea-b037-24df38bf8ed0n%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0585= bba3-fb88-41d6-b86c-167774c14eb9%40dashjr.org.
--------------wlnJsRPH3oHSVXEpZ1G0upSs--