From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 04 Oct 2025 16:39:56 -0700 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v5Br1-0006YD-Sf for bitcoindev@gnusha.org; Sat, 04 Oct 2025 16:39:56 -0700 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7a2acef26d7sf5809604a34.0 for ; Sat, 04 Oct 2025 16:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1759621189; x=1760225989; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=BT7wnSUnBoYCclYmO4TrqqV2odO1W8Vg4VRgcac4Hbs=; b=FvC9rJO7RJef3TJYPOE0ksnJqjfMKiwzLJIi1Gub8/XTP/jypcFAqb50fxzCO1z6vw 6JNJTezoW7l+z2X18PM6SyQHSa36hIhjp7cV0UmeFy00egXwA+sPYqrlY8uc3+LvHGmD xkOWkckARlzbzFUmdN0kM1QfAQ5jZJryqvbLMLguY+Ijbaky+wD90Cb13vUjdGicEefh ytvLFSrDf0FT42DL9y5UW8nQztwEkaQ816MJjViSyqZTImIxJx80CQkP5W+XtToujFdt dHbiPY4bO1eEzgI/M6a1OPLbaXojsA9E1TYH85os41bW7lIVLk8TKCMGu88YcCmV152X iklw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759621189; x=1760225989; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=BT7wnSUnBoYCclYmO4TrqqV2odO1W8Vg4VRgcac4Hbs=; b=SgN7glXo3aQVM6yJHhRbH1rAjat71qORDHwzCeqKweEOrkHmjt6FUVi2dOmYJRvXB0 zE37AwMyrmO0zSH3iAOlSzVFb0vzWfu8Swz2CSBuRov9F2mkPbko1sSBLmya7gRuoh8m e7uTp9CffKZiTI0doYKeGcZuOT31RRwSNAX7/nxivhEdQr7ot1Ew1T5O2kyzR6tcjf07 VkS5I7zbeHtaiPPDir/rRgLIkiZq1Zw6+Lcbwpua6hzG5cTWMMgcn/Sx/ORgWRlOfIW/ Jg2S//X823XWoSGmB/RdK+Mfn/P3r2uZx9g4FaTDYneU777FpyNj/wkEPpzlkcky3SYW 14bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759621189; x=1760225989; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=BT7wnSUnBoYCclYmO4TrqqV2odO1W8Vg4VRgcac4Hbs=; b=MNRzvR18VxVT9XLE09mNCZzlFGP0BOVpWio9fSINMrpjFpCFZ12wUHdtbWCJTU2Ucz O2zc3Y7NRNxmJCMxW9dXnOGKkC4BtesULxpNFJQtKiq/EiSit1COm1oB11a/VE21mBfn k7AUc8Gy4Or9r85hya2mmJwd6PrOrtxErckOGXxXaOWAUZMTRLcpR4R+ZsSzS42PT0ec By4/ozgYBU2+nJ08TAHE7xvsJDzA81/+CWuEEXWOCmD3rAwRKACzduW5zqhWyBegh++G Wv/roe1QOKR0ERJPFydRerOkIYpU82y2afMNZXqAdyoPqsK+jY5kMCwldfTZzZ2HPdtZ +OLg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV1LqO7+Xx4VoSrSZKMbpBVd++VNqcv0Dtbg5aF/bGX0v99vS8T8CG4qvpq+7WH0lBKl48eLDSsNLVj@gnusha.org X-Gm-Message-State: AOJu0YyGmU1K8kchi0HNi62V1kvaL0EmkMo+8KnJ2HGMUcvw+H6A7wDh 4/VzjuOjwgCsq9tqUP+s+n3f8sCAn9FWhJbClT3sM958Fc20IjBUigZC X-Google-Smtp-Source: AGHT+IEQRyt7Oh9Ll7Nav2QyVURxmnJgvDLjh/IqMkdLUffIE2LX/VG7tyne6MCMqutJ9LenPdcXGg== X-Received: by 2002:a05:6820:5046:b0:63d:b5ef:6cf7 with SMTP id 006d021491bc7-64e60374a6dmr3689943eaf.7.1759621189298; Sat, 04 Oct 2025 16:39:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6y8fNvGyefXTZHHdq8LEkPnZZubQKBCwCRIrhcTxwHhg==" Received: by 2002:a05:6820:2f10:b0:64c:f76:f8c8 with SMTP id 006d021491bc7-64dfd93e0d1ls574170eaf.0.-pod-prod-02-us; Sat, 04 Oct 2025 16:39:44 -0700 (PDT) X-Received: by 2002:a05:6808:13c4:b0:43d:20c9:974f with SMTP id 5614622812f47-43fc1799afdmr3688909b6e.12.1759621184790; Sat, 04 Oct 2025 16:39:44 -0700 (PDT) Received: by 2002:a05:690c:3383:b0:720:768:1935 with SMTP id 00721157ae682-77f9419d23cms7b3; Sat, 4 Oct 2025 16:12:54 -0700 (PDT) X-Received: by 2002:a05:690c:60c5:b0:77e:d606:cc1e with SMTP id 00721157ae682-77f94277283mr81335167b3.9.1759619573159; Sat, 04 Oct 2025 16:12:53 -0700 (PDT) Date: Sat, 4 Oct 2025 16:12:52 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: <1e0f9843-0f08-4dea-b037-24df38bf8ed0n@googlegroups.com> In-Reply-To: References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org> Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5978_111778777.1759619572827" X-Original-Sender: Jeremy.L.Rubin@gmail.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 (/) ------=_Part_5978_111778777.1759619572827 Content-Type: multipart/alternative; boundary="----=_Part_5979_1476183600.1759619572827" ------=_Part_5979_1476183600.1759619572827 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable - Limit taproot control block to 257 bytes (128 scripts max), or at least= =20 way less than it currently is. 340e36 scripts is completely 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 with=20 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 of= =20 executing, then you'd need depth 32. 128 depth was chosen because if a branch is (2^128 -1)/2^128 unlikely to=20 execute, then it's negligibly likely, the same order of probability as=20 being able to e.g. brute force a key.=20 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= =20 > after a year or two.=20 > > That sounds reasonable and it could work if we can agree on the specifics= =20 > of this proposal. As Jeremy also mentioned in his email, we could set up = an=20 > auto-renewing restriction lasting 1=E2=80=932 years with the option to re= move it=20 > 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 wro= te: > >> 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 softfor= k=20 >> anyway (see below about expiring this). >> >> - Limit taproot control block to 257 bytes (128 scripts max), or at leas= t=20 >> way less than it currently is. 340e36 scripts is completely 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 expecte= d=20 >> size. This could also be a temporary softfork, perhaps with a rolling=20 >> window, so future softforks could be free to lower weights should they b= e=20 >> 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 outpoints= =20 >> with greater than 520 bytes in the ScriptPubkey would be consensus inval= id.=20 >> >> 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 8= =20 >> being non OP_RETURN. I think after 15 years and not having discovered us= e=20 >> for 'large' ScriptPubkeys; the reward for not invalidating them at the= =20 >> consensus level is lower than the risk of their abuse.=20 >> >> -=20 >> *Reasons for *=20 >> - Makes DoS blocks likely impossible to create that would have any= =20 >> sufficient negative impact on the network.=20 >> - Leaves enough room for hooks long term >> - Would substantially reduce the divergence between consensus and= =20 >> relay policy=20 >> - Incredibly little use onchain as evidenced above.=20 >> - Could possibly reduce codebase complexity. Legacy Script is=20 >> largely considered a mess though this isn't a complete disablement= it=20 >> should reduce the total surface that is problematic.=20 >> - Would make it harder to use the ScriptPubkey as a 'large'=20 >> datacarrier.=20 >> - Possible UTXO set size bloat reduction. >> =20 >> - *Reasons Against *=20 >> - Bitcoin could need it in the future? Quantum? >> - Users could just create more outpoints.=20 >> =20 >> Thoughts? >> >> source of onchain data =20 >> >> >> PortlandHODL >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378= eb2c0c701n%40googlegroups.com=20 >> >> . >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebc= c778f57b0%40dashjr.org=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/= 1e0f9843-0f08-4dea-b037-24df38bf8ed0n%40googlegroups.com. ------=_Part_5979_1476183600.1759619572827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

- 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.<= /p>


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

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

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

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

<= div dir=3D"auto" class=3D"gmail_attr">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.=C2=A0

That sounds reasonable and it could work if we can agre= e 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 wit= h 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 <lu...@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 o= nchain 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 bitcoinde= v+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb= 2c0c701n%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+...@googlegro= ups.com.
To view this discussion visit https://groups.goog= le.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/bitcoind= ev/1e0f9843-0f08-4dea-b037-24df38bf8ed0n%40googlegroups.com.
------=_Part_5979_1476183600.1759619572827-- ------=_Part_5978_111778777.1759619572827--