path: root/a2/35a2e7b55d3277acc297548198c1b400ff9b49

Delivery-date: Fri, 03 Oct 2025 08:52:18 -0700
Received: from mail-oa1-f56.google.com ([209.85.160.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+bncBD7O3WHWY4JRBJ7C77DAMGQEGDXUWMI@googlegroups.com>)
	id 1v4i4v-0002Y4-PM
	for bitcoindev@gnusha.org; Fri, 03 Oct 2025 08:52:18 -0700
Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-30ccebce606sf289502fac.2
        for <bitcoindev@gnusha.org>; Fri, 03 Oct 2025 08:52:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1759506731; x=1760111531; 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=pcqFgys5ltiRNlp/5ThDl/aImHhXSOc+BnzXTqrKczQ=;
        b=SixTMdh0DyEgPnFuhO02Gs9+qLkBxrhhNvH04Fd/NTA5KruH0vLI106XyeOQRHzUYB
         Yhdw3FdNeV0jCfccV4SsL3mgN0D3mNrRHuv1fcya0j05PmDx72yuHWejfyNGjqrnFVrU
         lP+VaPCQDWkk90IzUoxSYomggeTkSPFLKGRXYk8ROH8+1P9jUmo8YP6dcdo5DWn6VjgW
         0ENEPPYLsUAGCNZ5mTSNnNZxPyo330EGFoCOHsshsFmOgZvISgrin3aqTi7bEM8ccn/m
         QNFo0rt/ueJBhbd6uI12EDgMrE8Vg7KLptai+dEuwXIg9eujRfqbPQe3n2c3A7r/XYwW
         9A2w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759506731; x=1760111531; 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=pcqFgys5ltiRNlp/5ThDl/aImHhXSOc+BnzXTqrKczQ=;
        b=Srh6m0U2cqt9CToFgxYITiTgXGnVQqE/jnD0N656AOAPs3HIPS2IZhnVyQYyiR0d7d
         +A4T7CjCHN3povAwTp58IJ8foAWQPi0LC/SgLl3Xm1jGid31IJgfcJZq57HKEOsQ/A/3
         7n/HZeOS0TiSNJpWYtANOGBswcb2+w2J71PmnTx/8VoO2av3YKo4Zi75PIad87B3fsZt
         0OaSV6awHLIZxJAEEKfStKOex8iuxtSIS+4fg39zky3XUqb3UitnBLnKO4P0ARehKuPy
         yQ54yzpA1czuvSZfbpOHJzuD66kMpDdccrGw7Ll2bzfsrglIiptehytJcz/gBIQacVDt
         oHRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759506731; x=1760111531;
        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=pcqFgys5ltiRNlp/5ThDl/aImHhXSOc+BnzXTqrKczQ=;
        b=JifE/wu+pBYlS3ORRqXSWM41NrSlGrxJ1Hzqmgn5ebSjuyXFZiCOs8pLq0Ipy0YkQA
         3gr/TjmMq0mj4gb0Xr7pxbjt0l3MurLzD9mQ6bsNiFkh6jMV6BqFll3XkKQOB8bU7GYE
         TkC8ed4ZaaWgI4zUDayTtEE2leM/CePB5gKqvGl2KSYTl4zcuiLciiWC8rVicQJ3trA9
         wx+PJAvVCjdnwnO4Jv+DxRmHfa9bxp8iYN7whr3r79gQlKMP88ZyxBQxc6lW/vCtoLdu
         7GplkEYb++C1T+Yx7LKyQTI4inKpy3c7ZKmoWE0eKNqDLrp1OMJJtmvIvxrez9/Er133
         6o0w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUyekcaaSz3ZqdoG9gOdnSbWAlRgHpM0EyUtbTBx/bCv9QCA6aiB6qfIWGULoqEca/VZBOYbyuId0EF@gnusha.org
X-Gm-Message-State: AOJu0Ywyr/SpkBo+IYsm7ONWGS6gy/yNks9QypmMiCs5g8Deqaqcw4bX
	8gHlNoLr/axmOES/mF+dg/PDZ4v+09MtleHHG4DLXBCgkaXQAIRQMDqt
X-Google-Smtp-Source: AGHT+IGE2iauBGCd42u3u3UQpiaQlAqKVCOhTM7XKf0S4HdQdoc1+FR05GbeTjyr8rv/8VWuNue3vQ==
X-Received: by 2002:a05:6871:413:b0:345:ecd6:8b7 with SMTP id 586e51a60fabf-3b1030fb164mr948375fac.11.1759506731514;
        Fri, 03 Oct 2025 08:52:11 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6Zhrnap0ViQxhj5EK6CNX8yB5+GgeDD75cgYFFMQzWmg=="
Received: by 2002:a05:6870:e0e:b0:31d:8f7d:c062 with SMTP id
 586e51a60fabf-3abe82759eels707618fac.0.-pod-prod-06-us; Fri, 03 Oct 2025
 08:52:06 -0700 (PDT)
X-Received: by 2002:a05:6808:1784:b0:439:ae49:9159 with SMTP id 5614622812f47-43fc1828ba0mr1330266b6e.36.1759506726835;
        Fri, 03 Oct 2025 08:52:06 -0700 (PDT)
Received: by 2002:a05:690c:ed6:b0:725:2535:e36 with SMTP id 00721157ae682-77f93fd870bms7b3;
        Fri, 3 Oct 2025 06:35:43 -0700 (PDT)
X-Received: by 2002:a05:690c:4908:b0:76b:50dc:99a4 with SMTP id 00721157ae682-77f9470196fmr42416797b3.47.1759498542532;
        Fri, 03 Oct 2025 06:35:42 -0700 (PDT)
Date: Fri, 3 Oct 2025 06:35:42 -0700 (PDT)
From: jeremy <jeremy.l.rubin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <63c19ec4-ab83-4280-a5b3-037ff1b1b126n@googlegroups.com>
In-Reply-To: <MH0kp4ehOxe8iikzhdxmFXM7GmIzpHGzGFujVeAdyUF_usOKf_CkToIBGSM2fB75TugGLsebVk8gM4OlS2VLHpGKIgmjkWDQuOwZeIr-F-E=@protonmail.com>
References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
 <842930fb-bede-408a-8380-776d4be4e094n@googlegroups.com>
 <MH0kp4ehOxe8iikzhdxmFXM7GmIzpHGzGFujVeAdyUF_usOKf_CkToIBGSM2fB75TugGLsebVk8gM4OlS2VLHpGKIgmjkWDQuOwZeIr-F-E=@protonmail.com>
Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520
 Bytes Consensus.
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_252_884706438.1759498542151"
X-Original-Sender: Jeremy.L.Rubin@gmail.com
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.5 (/)

------=_Part_252_884706438.1759498542151
Content-Type: multipart/alternative; 
	boundary="----=_Part_253_1701723995.1759498542152"

------=_Part_253_1701723995.1759498542152
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think that this type of rule is OK if we do it as a "sunsetting"=20
restriction -- e.g. a soft fork active for the next N blocks (N =3D e.g. 2=
=20
years, 5 years, 10 years).

We may yet find a compelling use for larger scriptpubkeys, and to me the=20
interactions between different key types is non-obvious.

An example of where big SPK is valuable v.s. e.g. Taproot, Segwit, P2SH is=
=20
if there is one big script path required in a two-tx protocol, and the=20
inclusion price must be paid by the proposed of the first tx. In this case,=
=20
we'd want the inclusion guaranteed by the first tx and then the cost isn't=
=20
paid (other than satisfaction cost).

You can argue against this example probably, but it is worth considering=20
that absence of evidence of use is not evidence of absence of use and I=20
myself feel that overall our understanding of Bitcoin transaction=20
programming possibilities is still early.  If you don't like this example,=
=20
I can give you others (probably).

As such, I'm NACK on a permanent restriction on what could be a valuable=20
use. But I do think it could be reasonable to set up an auto-renewing=20
restriction on a 1-2 year basis, and allow it to be removed if we later=20
decide we want them.

(N.B. this differs from past temporary soft fork proposals as it's a=20
restriction on something we think no one will do that we eventually lift,=
=20
rather than removing after a time an opcode that we expect people would=20
want to rely on.)

On Friday, October 3, 2025 at 7:03:09=E2=80=AFAM UTC-4 moonsettler wrote:

> Hi Floppy,
>
> There are only weak arguments for this proposal to extend to OP_RETURN, a=
t=20
> least nothing I would normally entertain;
> but also there are weak arguments to make an exception for OP_RETURN=20
> explicitly.
>
> People could just add many OP_RETURNs to a transaction, that makes it mor=
e=20
> cumbersome and marginally more expensive.
>
> BR,
> moonsettler
>
>
> On Friday, October 3rd, 2025 at 10:58 AM, /dev /fd0 <alice...@gmail.com>=
=20
> wrote:
>
> > Hi portlandhodl,
> >=20
> > We can't predict future usage, so it would be great if this was=20
> restricted to OP_RETURN. While there is no real use for a scriptPubKey=20
> larger than 520 bytes as shown in the data you shared, it is possible tha=
t=20
> users may create more OP_RETURN outputs after this change. It does not=20
> affect the UTXO set but will cost more and economically discourage the us=
e=20
> of multiple OP_RETURN outputs.
> >=20
> > /dev/fd0
> > floppy disk guy
> > On Friday, October 3, 2025 at 3:29:24=E2=80=AFAM UTC+5:30 PortlandHODL =
wrote:
> >=20
> > > 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.
> > >=20
> > > This is my gathering of information per BIP 0002
> > >=20
> > > After doing some research into the number of outpoints that would hav=
e=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 use=
=20
> for 'large' ScriptPubkeys; the reward for not invalidating them at the=20
> consensus level is lower than the risk of their abuse.
> > >=20
> > > - Reasons for
> > > - Makes DoS blocks likely impossible to create that would have any=20
> sufficient negative impact on the network.
> > > - Leaves enough room for hooks long term
> > > - Would substantially reduce the divergence between consensus and=20
> relay policy
> > > - Incredibly little use onchain as evidenced above.
> > > - Could possibly reduce codebase complexity. Legacy Script is largely=
=20
> considered a mess though this isn't a complete disablement it should redu=
ce=20
> the total surface that is problematic.
> > > - Would make it harder to use the ScriptPubkey as a 'large'=20
> datacarrier.
> > > - Possible UTXO set size bloat reduction.
> > >=20
> > > - Reasons Against
> > > - Bitcoin could need it in the future? Quantum?
> > > - Users could just create more outpoints.
> > >=20
> > > Thoughts?
> > >=20
> > > source of onchain data
> > >=20
> > > 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+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/842930fb-bede-408a-8380-776d=
4be4e094n%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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
63c19ec4-ab83-4280-a5b3-037ff1b1b126n%40googlegroups.com.

------=_Part_253_1701723995.1759498542152
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think that this type of rule is OK if we do it as a "sunsetting" restrict=
ion -- e.g. a soft fork active for the next N blocks (N =3D e.g. 2 years, 5=
 years, 10 years).<div><br /></div><div>We may yet find a compelling use fo=
r larger scriptpubkeys, and to me the interactions between different key ty=
pes is non-obvious.</div><div><br /></div><div>An example of where big SPK =
is valuable v.s. e.g. Taproot, Segwit, P2SH is if there is one big script p=
ath required in a two-tx protocol, and the inclusion price must be paid by =
the proposed of the first tx. In this case, we'd want the inclusion guarant=
eed by the first tx and then the cost isn't paid (other than satisfaction c=
ost).</div><div><br /></div><div>You can argue against this example probabl=
y, but it is worth considering that absence of evidence of use is not evide=
nce of absence of use and I myself feel that overall our understanding of B=
itcoin transaction programming possibilities is still early.=C2=A0 If you d=
on't like this example, I can give you others (probably).</div><div><br /><=
/div><div>As such, I'm NACK on a permanent restriction on what could be a v=
aluable use. But I do think it could be reasonable to set up an auto-renewi=
ng restriction on a 1-2 year basis, and allow it to be removed if we later =
decide we want them.</div><div><br /></div><div>(N.B. this differs from pas=
t temporary soft fork proposals as it's a restriction on something we think=
 no one will do that we eventually lift, rather than removing after a time =
an opcode that we expect people would want to rely on.)</div><div><div><br =
/></div></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_a=
ttr">On Friday, October 3, 2025 at 7:03:09=E2=80=AFAM UTC-4 moonsettler wro=
te:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Floppy=
,
<br>
<br>There are only weak arguments for this proposal to extend to OP_RETURN,=
 at least nothing I would normally entertain;
<br>but also there are weak arguments to make an exception for OP_RETURN ex=
plicitly.
<br>
<br>People could just add many OP_RETURNs to a transaction, that makes it m=
ore cumbersome and marginally more expensive.
<br>
<br>BR,
<br>moonsettler
<br>
<br>
<br>On Friday, October 3rd, 2025 at 10:58 AM, /dev /fd0 &lt;<a href data-em=
ail-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Hi portlandhodl,
<br>&gt;=20
<br>&gt; We can&#39;t predict future usage, so it would be great if this wa=
s restricted to OP_RETURN. While there is no real use for a scriptPubKey la=
rger than 520 bytes as shown in the data you shared, it is possible that us=
ers may create more OP_RETURN outputs after this change. It does not affect=
 the UTXO set but will cost more and economically discourage the use of mul=
tiple OP_RETURN outputs.
<br>&gt;=20
<br>&gt; /dev/fd0
<br>&gt; floppy disk guy
<br>&gt; On Friday, October 3, 2025 at 3:29:24=E2=80=AFAM UTC+5:30 Portland=
HODL wrote:
<br>&gt;=20
<br>&gt; &gt; Proposing: Softfork to after (n) block height; the creation o=
f outpoints with greater than 520 bytes in the ScriptPubkey would be consen=
sus invalid.
<br>&gt; &gt;=20
<br>&gt; &gt; This is my gathering of information per BIP 0002
<br>&gt; &gt;=20
<br>&gt; &gt; After doing some research into the number of outpoints that w=
ould 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 discovere=
d use for &#39;large&#39; ScriptPubkeys; the reward for not invalidating th=
em at the consensus level is lower than the risk of their abuse.
<br>&gt; &gt;=20
<br>&gt; &gt; -   Reasons for
<br>&gt; &gt;     -   Makes DoS blocks likely impossible to create that wou=
ld have any sufficient negative impact on the network.
<br>&gt; &gt;     -   Leaves enough room for hooks long term
<br>&gt; &gt;     -   Would substantially reduce the divergence between con=
sensus and relay policy
<br>&gt; &gt;     -   Incredibly little use onchain as evidenced above.
<br>&gt; &gt;     -   Could possibly reduce codebase complexity. Legacy Scr=
ipt is largely considered a mess though this isn&#39;t a complete disableme=
nt it should reduce the total surface that is problematic.
<br>&gt; &gt;     -   Would make it harder to use the ScriptPubkey as a &#3=
9;large&#39; datacarrier.
<br>&gt; &gt;     -   Possible UTXO set size bloat reduction.
<br>&gt; &gt;        =20
<br>&gt; &gt; -   Reasons Against
<br>&gt; &gt;     -   Bitcoin could need it in the future? Quantum?
<br>&gt; &gt;     -   Users could just create more outpoints.
<br>&gt; &gt;=20
<br>&gt; &gt; Thoughts?
<br>&gt; &gt;=20
<br>&gt; &gt; source of onchain data
<br>&gt; &gt;=20
<br>&gt; &gt; PortlandHODL
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/842930fb-bede-408a-8380-776d4be4e094n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/=
842930fb-bede-408a-8380-776d4be4e094n%2540googlegroups.com&amp;source=3Dgma=
il&amp;ust=3D1759584378134000&amp;usg=3DAOvVaw2j6KWtoVVncsgCkYbNXejM">https=
://groups.google.com/d/msgid/bitcoindev/842930fb-bede-408a-8380-776d4be4e09=
4n%40googlegroups.com</a>.
<br></blockquote></div>

<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/63c19ec4-ab83-4280-a5b3-037ff1b1b126n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/63c19ec4-ab83-4280-a5b3-037ff1b1b126n%40googlegroups.com</a>.<br />

------=_Part_253_1701723995.1759498542152--

------=_Part_252_884706438.1759498542151--