* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 20:42 [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus PortlandHODL
@ 2025-10-02 22:19 ` Andrew Poelstra
2025-10-02 22:46 ` Andrew Poelstra
2025-10-02 22:47 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-02 22:27 ` Brandon Black
` (4 subsequent siblings)
5 siblings, 2 replies; 19+ messages in thread
From: Andrew Poelstra @ 2025-10-02 22:19 UTC (permalink / raw)
To: PortlandHODL; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]
On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.
>
Personally, I like this. Unlike restrictions on opcode behavior or
witness data, it is impossible for there to be any existing UTXOs which
"might turn out to need" scriptpubkeys greater than 520 bytes. In a
post-covenant world I suppose this could change.
There is a risk of confiscation of coins which have pre-signed but
unpublished transactions spending them to new outputs with large
scriptPubKeys. Due to long-standing standardness rules, and the presence
of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
such transactions exist.
In any case, if confiscation is a worry, as always we can exempt the
current UTXO set from the rule -- if you are only spending outputs that
existed prior to the new rule, your new UTXOs are allowed to be large.
I would even suggest going lower than 520 bytes.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--
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/aN76f2wKPHFcj8qt%40mail.wpsoftware.net.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 22:19 ` Andrew Poelstra
@ 2025-10-02 22:46 ` Andrew Poelstra
2025-10-02 22:47 ` 'moonsettler' via Bitcoin Development Mailing List
1 sibling, 0 replies; 19+ messages in thread
From: Andrew Poelstra @ 2025-10-02 22:46 UTC (permalink / raw)
To: PortlandHODL; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]
On Thu, Oct 02, 2025 at 10:19:43PM +0000, Andrew Poelstra wrote:
> On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.
> >
>
> Personally, I like this. Unlike restrictions on opcode behavior or
> witness data, it is impossible for there to be any existing UTXOs which
> "might turn out to need" scriptpubkeys greater than 520 bytes. In a
> post-covenant world I suppose this could change.
>
> There is a risk of confiscation of coins which have pre-signed but
> unpublished transactions spending them to new outputs with large
> scriptPubKeys. Due to long-standing standardness rules, and the presence
> of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
> such transactions exist.
>
To add to this -- if we whitelisted existing UTXOs to preserve the
validity of pre-signed transactions, this still might not be enough;
there could be arbitrarily long chains of pre-signed transaction.
This is still possible to overcome -- we whitelist all existing UTXOs,
their descendants (UTXOs created from transactions which only spend
existing UTXOs), and so on. The result would be that from the point
of activation, new coinbase outputs would have limited size, as would
their children, and so on, and the limit would spread outward.
I don't think this is a great idea -- it would be technically hard to
implement and slow deployment indefinitely. But I am bringing it up
so people are aware that it's possible to address the confiscation
issue, no matter how rigid you are about it.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--
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/aN8A3TnDiwiNlunQ%40mail.wpsoftware.net.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 22:19 ` Andrew Poelstra
2025-10-02 22:46 ` Andrew Poelstra
@ 2025-10-02 22:47 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 7:11 ` Garlo Nicon
1 sibling, 1 reply; 19+ messages in thread
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-10-02 22:47 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: PortlandHODL, Bitcoin Development Mailing List
Hi All,
Agreed, this is something we should consider.
> I would even suggest going lower than 520 bytes.
200 should be enough.
If this should apply to OP_RETURN (nulldata) or not, is something I can't make my mind up on.
BR,
moonsettler
Sent with Proton Mail secure email.
On Friday, October 3rd, 2025 at 12:31 AM, Andrew Poelstra <apoelstra@wpsoftware•net> wrote:
> On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.
>
>
> Personally, I like this. Unlike restrictions on opcode behavior or
> witness data, it is impossible for there to be any existing UTXOs which
> "might turn out to need" scriptpubkeys greater than 520 bytes. In a
> post-covenant world I suppose this could change.
>
> There is a risk of confiscation of coins which have pre-signed but
> unpublished transactions spending them to new outputs with large
> scriptPubKeys. Due to long-standing standardness rules, and the presence
> of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
> such transactions exist.
>
> In any case, if confiscation is a worry, as always we can exempt the
> current UTXO set from the rule -- if you are only spending outputs that
> existed prior to the new rule, your new UTXOs are allowed to be large.
>
>
> I would even suggest going lower than 520 bytes.
>
>
> --
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
> --
> 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/aN76f2wKPHFcj8qt%40mail.wpsoftware.net.
--
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/FIpHCygrCyfUu_jNgLJumi-06nYm5P6rmUVc01R3SmhdMVbQo9-8Lyxbh5yGUPrHFQRtyYQ_RvgltQNuoulyXmdnuQSklTab_sM5X63FUs4%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 22:47 ` 'moonsettler' via Bitcoin Development Mailing List
@ 2025-10-03 7:11 ` Garlo Nicon
0 siblings, 0 replies; 19+ messages in thread
From: Garlo Nicon @ 2025-10-03 7:11 UTC (permalink / raw)
To: moonsettler
Cc: Andrew Poelstra, PortlandHODL, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3851 bytes --]
> 200 should be enough.
Maybe. But "520" is a battle-tested value, when it comes to the maximum
allowed stack push. Picking "520" should be safe enough, and it has a
higher chances to be accepted as a new consensus rule. Also, if it turns
out, that a lower limit, like "200" is enough, then it can be lowered later
(but bumping it would be much harder).
> If this should apply to OP_RETURN (nulldata) or not, is something I can't
make my mind up on.
I think it should be applied everywhere. And if someone needs a larger
OP_RETURN, then that Script can be taken, wrapped into TapScript branch,
and included to any Taproot address.
pt., 3 paź 2025 o 00:49 'moonsettler' via Bitcoin Development Mailing List <
bitcoindev@googlegroups.com> napisał(a):
> Hi All,
>
> Agreed, this is something we should consider.
>
> > I would even suggest going lower than 520 bytes.
>
> 200 should be enough.
>
> If this should apply to OP_RETURN (nulldata) or not, is something I can't
> make my mind up on.
>
> BR,
> moonsettler
>
> Sent with Proton Mail secure email.
>
> On Friday, October 3rd, 2025 at 12:31 AM, Andrew Poelstra <
> apoelstra@wpsoftware•net> wrote:
>
> > On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.
> >
> >
> > Personally, I like this. Unlike restrictions on opcode behavior or
> > witness data, it is impossible for there to be any existing UTXOs which
> > "might turn out to need" scriptpubkeys greater than 520 bytes. In a
> > post-covenant world I suppose this could change.
> >
> > There is a risk of confiscation of coins which have pre-signed but
> > unpublished transactions spending them to new outputs with large
> > scriptPubKeys. Due to long-standing standardness rules, and the presence
> > of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
> > such transactions exist.
> >
> > In any case, if confiscation is a worry, as always we can exempt the
> > current UTXO set from the rule -- if you are only spending outputs that
> > existed prior to the new rule, your new UTXOs are allowed to be large.
> >
> >
> > I would even suggest going lower than 520 bytes.
> >
> >
> > --
> > Andrew Poelstra
> > Director, Blockstream Research
> > Email: apoelstra at wpsoftware.net
> > Web: https://www.wpsoftware.net/andrew
> >
> > The sun is always shining in space
> > -Justin Lewis-Webster
> >
> > --
> > 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/aN76f2wKPHFcj8qt%40mail.wpsoftware.net
> .
>
> --
> 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/FIpHCygrCyfUu_jNgLJumi-06nYm5P6rmUVc01R3SmhdMVbQo9-8Lyxbh5yGUPrHFQRtyYQ_RvgltQNuoulyXmdnuQSklTab_sM5X63FUs4%3D%40protonmail.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/CAN7kyNj0zWY8mRtitZNGSrexpQES6U4txswcEgd6BZQUYKX_tw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5464 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 20:42 [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus PortlandHODL
2025-10-02 22:19 ` Andrew Poelstra
@ 2025-10-02 22:27 ` Brandon Black
2025-10-03 1:21 ` [bitcoindev] " /dev /fd0
` (3 subsequent siblings)
5 siblings, 0 replies; 19+ messages in thread
From: Brandon Black @ 2025-10-02 22:27 UTC (permalink / raw)
To: PortlandHODL; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]
Love this idea.
I think "users will just use more outputs" is the one argument against. But with witness size not limited in this way, I don't see that being a problem.
If this avoids any of the fiddliness involved in avoiding DOS with GCC, I think we should do it.
Best,
Brandon
--Brandon, sent by an Android
Oct 2, 2025 15:00:22 PortlandHODL <admin@qrsnap•io>:
> 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
> * *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 [https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubkeys.csv]
>
> 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%40googlegroups.com[https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com?utm_medium=email&utm_source=footer].
--
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/2e5be000-c054-44ea-818c-653dc11f0901%40reardencode.com.
[-- Attachment #2: Type: text/html, Size: 4301 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 20:42 [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus PortlandHODL
2025-10-02 22:19 ` Andrew Poelstra
2025-10-02 22:27 ` Brandon Black
@ 2025-10-03 1:21 ` /dev /fd0
2025-10-03 10:46 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 13:59 ` Andrew Poelstra
2025-10-03 13:21 ` [bitcoindev] " Peter Todd
` (2 subsequent siblings)
5 siblings, 2 replies; 19+ messages in thread
From: /dev /fd0 @ 2025-10-03 1:21 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2520 bytes --]
Hi portlandhodl,
We can't predict future usage, so it would be great if this was restricted
to OP_RETURN. While there is no real use for a scriptPubKey larger than 520
bytes as shown in the data you shared, it is possible that users 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 multiple
OP_RETURN outputs.
/dev/fd0
floppy disk guy
On Friday, October 3, 2025 at 3:29:24 AM UTC+5:30 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 *
> - 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
> <https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubkeys.csv>
>
> 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/842930fb-bede-408a-8380-776d4be4e094n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3260 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 1:21 ` [bitcoindev] " /dev /fd0
@ 2025-10-03 10:46 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 11:26 ` /dev /fd0
2025-10-03 13:35 ` jeremy
2025-10-03 13:59 ` Andrew Poelstra
1 sibling, 2 replies; 19+ messages in thread
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-10-03 10:46 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
Hi Floppy,
There are only weak arguments for this proposal to extend to OP_RETURN, at least nothing I would normally entertain;
but also there are weak arguments to make an exception for OP_RETURN explicitly.
People could just add many OP_RETURNs to a transaction, that makes it more cumbersome and marginally more expensive.
BR,
moonsettler
On Friday, October 3rd, 2025 at 10:58 AM, /dev /fd0 <alicexbtong@gmail•com> wrote:
> Hi portlandhodl,
>
> We can't predict future usage, so it would be great if this was restricted to OP_RETURN. While there is no real use for a scriptPubKey larger than 520 bytes as shown in the data you shared, it is possible that users 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 multiple OP_RETURN outputs.
>
> /dev/fd0
> floppy disk guy
> On Friday, October 3, 2025 at 3:29:24 AM UTC+5:30 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
> > - 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/842930fb-bede-408a-8380-776d4be4e094n%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/MH0kp4ehOxe8iikzhdxmFXM7GmIzpHGzGFujVeAdyUF_usOKf_CkToIBGSM2fB75TugGLsebVk8gM4OlS2VLHpGKIgmjkWDQuOwZeIr-F-E%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 10:46 ` 'moonsettler' via Bitcoin Development Mailing List
@ 2025-10-03 11:26 ` /dev /fd0
2025-10-03 13:35 ` jeremy
1 sibling, 0 replies; 19+ messages in thread
From: /dev /fd0 @ 2025-10-03 11:26 UTC (permalink / raw)
To: moonsettler; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3806 bytes --]
Hi moonsettler,
> People could just add many OP_RETURNs to a transaction, that makes it
more cumbersome and marginally more expensive.
This is exactly what I wrote in my email and I consider it a positive
thing. I think we are just looking at this proposal from different
perspectives.
/dev/fd0
floppy disk guy
On Fri, Oct 3, 2025 at 4:16 PM moonsettler <moonsettler@protonmail•com>
wrote:
> Hi Floppy,
>
> There are only weak arguments for this proposal to extend to OP_RETURN, at
> least nothing I would normally entertain;
> but also there are weak arguments to make an exception for OP_RETURN
> explicitly.
>
> People could just add many OP_RETURNs to a transaction, that makes it more
> cumbersome and marginally more expensive.
>
> BR,
> moonsettler
>
>
> On Friday, October 3rd, 2025 at 10:58 AM, /dev /fd0 <alicexbtong@gmail•com>
> wrote:
>
> > Hi portlandhodl,
> >
> > We can't predict future usage, so it would be great if this was
> restricted to OP_RETURN. While there is no real use for a scriptPubKey
> larger than 520 bytes as shown in the data you shared, it is possible that
> users 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 multiple OP_RETURN outputs.
> >
> > /dev/fd0
> > floppy disk guy
> > On Friday, October 3, 2025 at 3:29:24 AM UTC+5:30 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
> > > - 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/842930fb-bede-408a-8380-776d4be4e094n%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/CALiT-Zop43oiYxz1qaLm8RGZHOrd-_antFksY2VfgpzrKqPzCg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5075 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 10:46 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 11:26 ` /dev /fd0
@ 2025-10-03 13:35 ` jeremy
1 sibling, 0 replies; 19+ messages in thread
From: jeremy @ 2025-10-03 13:35 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 4890 bytes --]
I think that this type of rule is OK if we do it as a "sunsetting"
restriction -- e.g. a soft fork active for the next N blocks (N = e.g. 2
years, 5 years, 10 years).
We may yet find a compelling use for larger scriptpubkeys, and to me the
interactions between different key types is non-obvious.
An example of where big SPK is valuable v.s. e.g. Taproot, Segwit, P2SH is
if there is one big script path 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 guaranteed by the first tx and then the cost isn't
paid (other than satisfaction cost).
You can argue against this example probably, but it is worth considering
that absence of evidence of use is not evidence of absence of use and I
myself feel that overall our understanding of Bitcoin transaction
programming possibilities is still early. If you don't like this example,
I can give you others (probably).
As such, I'm NACK on a permanent restriction on what could be a valuable
use. But I do think it could be reasonable to set up an auto-renewing
restriction on a 1-2 year basis, and allow it to be removed if we later
decide we want them.
(N.B. this differs from past 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.)
On Friday, October 3, 2025 at 7:03:09 AM UTC-4 moonsettler wrote:
> Hi Floppy,
>
> There are only weak arguments for this proposal to extend to OP_RETURN, at
> least nothing I would normally entertain;
> but also there are weak arguments to make an exception for OP_RETURN
> explicitly.
>
> People could just add many OP_RETURNs to a transaction, that makes it more
> cumbersome and marginally more expensive.
>
> BR,
> moonsettler
>
>
> On Friday, October 3rd, 2025 at 10:58 AM, /dev /fd0 <alice...@gmail•com>
> wrote:
>
> > Hi portlandhodl,
> >
> > We can't predict future usage, so it would be great if this was
> restricted to OP_RETURN. While there is no real use for a scriptPubKey
> larger than 520 bytes as shown in the data you shared, it is possible that
> users 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 multiple OP_RETURN outputs.
> >
> > /dev/fd0
> > floppy disk guy
> > On Friday, October 3, 2025 at 3:29:24 AM UTC+5:30 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
> > > - 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+...@googlegroups•com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/842930fb-bede-408a-8380-776d4be4e094n%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/63c19ec4-ab83-4280-a5b3-037ff1b1b126n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6247 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 1:21 ` [bitcoindev] " /dev /fd0
2025-10-03 10:46 ` 'moonsettler' via Bitcoin Development Mailing List
@ 2025-10-03 13:59 ` Andrew Poelstra
2025-10-03 14:18 ` /dev /fd0
1 sibling, 1 reply; 19+ messages in thread
From: Andrew Poelstra @ 2025-10-03 13:59 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
On Thu, Oct 02, 2025 at 06:21:18PM -0700, /dev /fd0 wrote:
>
> We can't predict future usage,
Aside from proof-of-publication (i.e. data storage directly in the UTXO
set) there is no usage of script which can't be equally (or better)
accomplished by using a Segwit v0 or Taproot script.
> so it would be great if this was restricted
> to OP_RETURN. While there is no real use for a scriptPubKey larger than 520
> bytes as shown in the data you shared, it is possible that users 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 multiple
> OP_RETURN outputs.
>
Restricting it to OP_RETURN would have zero effect on people trying to
use scriptpubkeys for data storage. They would switch to any of the 65
or so other OP_RETURN equivalents, and failing that, switch to
OP_RESERVED, then to OP_FALSE, then to `0 1 EQVERIFY`, and so on. A
restriction that applies specifically to OP_RETURN outputs is no
restriction at all.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--
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/aN_Wz5YbZ9NieQu0%40mail.wpsoftware.net.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 13:59 ` Andrew Poelstra
@ 2025-10-03 14:18 ` /dev /fd0
2025-10-03 14:59 ` Andrew Poelstra
0 siblings, 1 reply; 19+ messages in thread
From: /dev /fd0 @ 2025-10-03 14:18 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]
Hi Andrew,
> Restricting it to OP_RETURN would have zero effect on people trying to
use scriptpubkeys for data storage.
1. The data shows that nobody is using scriptPubKeys for more than 520
bytes. In fact, people have found new ways to encode data in transactions.
Example: [Merkle path][0] in taproot control block
2. If this applies to all scriptPubKeys, it could negatively affect the
[UTXO set][1] size because multiple outputs is an alternative if someone
really wants to use scriptPubKey for data.
[0]:
https://mempool.space/tx/c5714af322cd2ba94adf3d74325eb17f03d029ad2bf47dc54c3d929833c02628
[1]: https://mainnet.observer/charts/utxoset-size/
/dev/fd0
floppy disk guy
On Fri, Oct 3, 2025 at 7:29 PM Andrew Poelstra <apoelstra@wpsoftware•net>
wrote:
> On Thu, Oct 02, 2025 at 06:21:18PM -0700, /dev /fd0 wrote:
> >
> > We can't predict future usage,
>
> Aside from proof-of-publication (i.e. data storage directly in the UTXO
> set) there is no usage of script which can't be equally (or better)
> accomplished by using a Segwit v0 or Taproot script.
>
> > so it would be great if this was restricted
> > to OP_RETURN. While there is no real use for a scriptPubKey larger than
> 520
> > bytes as shown in the data you shared, it is possible that users 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 multiple
> > OP_RETURN outputs.
> >
>
> Restricting it to OP_RETURN would have zero effect on people trying to
> use scriptpubkeys for data storage. They would switch to any of the 65
> or so other OP_RETURN equivalents, and failing that, switch to
> OP_RESERVED, then to OP_FALSE, then to `0 1 EQVERIFY`, and so on. A
> restriction that applies specifically to OP_RETURN outputs is no
> restriction at all.
>
>
> --
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
>
--
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/CALiT-ZpJ_F2UrvUwRjgMukxQJ%2Bs8GVzgDCHWt%3DzMR%2BHkMDDWWQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3561 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 14:18 ` /dev /fd0
@ 2025-10-03 14:59 ` Andrew Poelstra
2025-10-03 16:15 ` Anthony Towns
0 siblings, 1 reply; 19+ messages in thread
From: Andrew Poelstra @ 2025-10-03 14:59 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2873 bytes --]
On Fri, Oct 03, 2025 at 07:48:38PM +0530, /dev /fd0 wrote:
> Hi Andrew,
>
> > Restricting it to OP_RETURN would have zero effect on people trying to
> use scriptpubkeys for data storage.
>
> 1. The data shows that nobody is using scriptPubKeys for more than 520
> bytes. In fact, people have found new ways to encode data in transactions.
> Example: [Merkle path][0] in taproot control block
>
I'm relieved to hear this -- if you must embed data it is much cheaper
to do so in witness data, exactly because this data puts less load on
the network (in particular it does not need to be stored by non-archival
nodes).
Unfortunately, the evidence from the current "filters" debate, where in
the current 80-byte policy limit is filtering transactions that actually
appear in blocks, suggests that we just need to wait for the "on-chain
bitcoin spam" market to have a shift in sentiment before we have people
blowing past 520 bytes or beyond.
Adding a hard consensus limit seems harmless, and will put a hard
barrier against any such sentiment shifts.
If "it's cheaper to use witness data" were enough of a barrier, nobody
would be using OP_RETURN outputs today except for opentimestamps and
maybe some other super-low-load applications.
> 2. If this applies to all scriptPubKeys, it could negatively affect the
> [UTXO set][1] size because multiple outputs is an alternative if someone
> really wants to use scriptPubKey for data.
>
Good point! But if they are forced to use multiple outputs this will
increase the cost for them even further (and force them to split up
their data, which may force some technical pain even if the network
fees aren't enough).
I'm no spammer sociologist, but at some point if we can force the cost
difference between witness spam and UTXO-set spam high enough, nobody
will choose the latter, right?
And if not -- one of the most serious problems with spam is that it
muscles out protocols like LN or Ark by out-spending them on block
space, preventing them from gaining the network effects they would
need to spend a comparable amount. Every marginal cost we add to
spammers increases the delta by which they need to out-spend.
> [0]:
> https://mempool.space/tx/c5714af322cd2ba94adf3d74325eb17f03d029ad2bf47dc54c3d929833c02628
> [1]: https://mainnet.observer/charts/utxoset-size/
>
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--
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/aN_k1EAXZ0schWDs%40mail.wpsoftware.net.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 14:59 ` Andrew Poelstra
@ 2025-10-03 16:15 ` Anthony Towns
0 siblings, 0 replies; 19+ messages in thread
From: Anthony Towns @ 2025-10-03 16:15 UTC (permalink / raw)
To: Andrew Poelstra, Bitcoin Development Mailing List
On Fri, Oct 03, 2025 at 02:59:32PM +0000, Andrew Poelstra wrote:
> If "it's cheaper to use witness data" were enough of a barrier, nobody
> would be using OP_RETURN outputs today except for opentimestamps and
> maybe some other super-low-load applications.
It isn't chepaer to use witness data until you're publishing more than
~143 bytes of data, due to the overhead of the setup transaction. (It's
also not cheaper if you want extremely easy proof of publication of
the data)
Excluding the couple of months between the topic of increasing the
OP_RETURN limit was raised on this list and the increased limit was
merged into Bitcoin Core master, there have, in fact, been very few
OP_RETURN outputs generated that are above the ~143B size. In particular,
between blocks 900k and 915,843 I get:
15,003,149 total OP_RETURN outputs
131 OP_RETURN outputs larger than 83 bytes
81 OP_RETURN outputs of 144 bytes or more
19,707 OP_RETURN outputs with non-zero value
cf https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3341177765
Cheers,
aj
--
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/aN_2qZzAu9gxa1h0%40erisian.com.au.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 20:42 [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus PortlandHODL
` (2 preceding siblings ...)
2025-10-03 1:21 ` [bitcoindev] " /dev /fd0
@ 2025-10-03 13:21 ` Peter Todd
2025-10-03 16:52 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 15:42 ` Anthony Towns
2025-10-03 20:02 ` Luke Dashjr
5 siblings, 1 reply; 19+ messages in thread
From: Peter Todd @ 2025-10-03 13:21 UTC (permalink / raw)
To: PortlandHODL; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]
On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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 *
> - Makes DoS blocks likely impossible to create that would have any
> sufficient negative impact on the network.
Further restricting v0 scripts is sufficient to achieve this goal. We do not
need to actually prohibit >520 byte pushes.
> - 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?
NACK, for exactly this reason. It's hard to predict what kind of math will be
needed in the future for future signature algorithms. With taproot, we include
bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
want to do something similar with >520byte pubkeys for some future signature
algorithm (e.g. quantum hard) or some other difficult to predict technical
upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
this discussion).
> - Users could just create more outpoints.
The second reason for my NACK. It makes no significant difference whether or
not data is contiguous or split across multiple outputs. All the same concerns
about arbitrary data ("spam") exist and will continue to be argued over even if
we do a soft-fork to prohibit this. All we'll done is have used up valuable dev
and political resources.
--
https://petertodd.org 'peter'[:-1]@petertodd.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/bitcoindev/aN_N4i4zZ5Dt8TdG%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 13:21 ` [bitcoindev] " Peter Todd
@ 2025-10-03 16:52 ` 'moonsettler' via Bitcoin Development Mailing List
0 siblings, 0 replies; 19+ messages in thread
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-10-03 16:52 UTC (permalink / raw)
To: Peter Todd; +Cc: PortlandHODL, Bitcoin Development Mailing List
> NACK, for exactly this reason. It's hard to predict what kind of math will be
> needed in the future for future signature algorithms. With taproot, we include
> bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
> want to do something similar with >520byte pubkeys for some future signature
>
> algorithm (e.g. quantum hard) or some other difficult to predict technical
> upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
>
> this discussion).
No matter how large a pubkey script you need, you can just delegate to the
witness if you have a cryptographically secure hash function.
Hard to even imagine needing anywhere near 4096 bits for that.
The going assumption for quantum algos is they could halve the bit strength of
a hash function, but SHA512 seems quiet robust even under worst assumptions.
And it's not enough to find ANY collision for a script or some Merkle root.
Putting the unlocking conditions into the UTXO set does not seem like a healthy
idea to me anyhow.
BR,
moonsettler
PS:
No hard opinion on temporary vs final restrictions. I wouldn't worry about it.
Sent with Proton Mail secure email.
On Friday, October 3rd, 2025 at 5:51 PM, Peter Todd <pete@petertodd•org> wrote:
> On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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 *
> > - Makes DoS blocks likely impossible to create that would have any
> > sufficient negative impact on the network.
>
>
> Further restricting v0 scripts is sufficient to achieve this goal. We do not
> need to actually prohibit >520 byte pushes.
>
> > - 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?
>
>
> NACK, for exactly this reason. It's hard to predict what kind of math will be
> needed in the future for future signature algorithms. With taproot, we include
> bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
> want to do something similar with >520byte pubkeys for some future signature
>
> algorithm (e.g. quantum hard) or some other difficult to predict technical
> upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
>
> this discussion).
>
> > - Users could just create more outpoints.
>
>
> The second reason for my NACK. It makes no significant difference whether or
> not data is contiguous or split across multiple outputs. All the same concerns
> about arbitrary data ("spam") exist and will continue to be argued over even if
> we do a soft-fork to prohibit this. All we'll done is have used up valuable dev
> and political resources.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.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/bitcoindev/aN_N4i4zZ5Dt8TdG%40petertodd.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/bitcoindev/ONFWceYdQT0aizGwn2vyyzdr2RZ9GlQ7vAfNfIRRO_IGsTaX-l3bghNiygjXmccG8UJO_7pxrAr2ZKbUrlvNrAZ83EfyPjzuAR26J7xp4bw%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 20:42 [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus PortlandHODL
` (3 preceding siblings ...)
2025-10-03 13:21 ` [bitcoindev] " Peter Todd
@ 2025-10-03 15:42 ` Anthony Towns
2025-10-03 20:02 ` Luke Dashjr
5 siblings, 0 replies; 19+ messages in thread
From: Anthony Towns @ 2025-10-03 15:42 UTC (permalink / raw)
To: PortlandHODL; +Cc: Bitcoin Development Mailing List
On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.
> - Leaves enough room for hooks long term
> - Bitcoin could need it in the future?
One place where large scriptPubKeys could be useful is in script caching.
Suppose we have a future where complicated smart contracts are common;
eg perhaps some future version of lightning implemented using opcodes
from the great-script-restoration has a 9,000 byte script that is
used for every uncooperative close, and that lightning is so prevelant,
uncooperative closes are common.
In that scenario, we might like to be able to cache the 9,000 byte
script, and just invoke it by reference. One way to do that would
be to hardcode that script into consensus and soft-fork it in as a
new opcode. A more flexible alternative, however, would be to put that
script in our existing database, ie the utxo set, and look it up via its
36 bit txid/vout reference. To avoid permanently bloating the utxo set,
we could make such outputs expire after perhaps 100k blocks, and perhaps
increase the "weight" of creating such utxos by 10x, so that it's only
economical if the script is going to be used ~40x before it expires.
Using the utxo set here rather than creating a new database makes upgrades
easier; you don't have to rescan blocks to populate the script cache
database once you upgrade to a node version supporting script caching.
So I think there's potential uses for this flexibility that it wouldn't
be wise to just throw away.
(If you restricted the change to only applying to scripts that used
non-push operators, that would probably still provide upgrade flexibility
while also preventing potential script abuses. But it wouldn't do anything
to prevent publishing data)
> - Possible UTXO set size bloat reduction.
I don't think this works -- breaking up a scriptPubKey across multiple
utxos increases the utxo set bloat significantly, as in addition to the
scriptPubKey, each utxo includes a key (the 36 bytes for txid and vout),
an amount (8 bytes), a coinbase flag and a height (4 bytes), and likely
additional indexing data to keep lookups efficient.
If you're putting 10kB into the utxo set, then that's perhaps 50B of
overhead for a single entry (ie 0.5%); if you have to split it into 20x
500B entries with 50B overhead each, that's 1kB of overhead in total
(ie 10%).
> - Would make it harder to use the ScriptPubkey as a 'large'
> datacarrier.
This seems to be a bad goal to me; ie one that doesn't achieve anything
positive in reducing the bad things you want to prevent, but does make
things worse for other users you want to support. Breaking up data
and recovering it is straightforward, and already supported by various
Bitcoin-specific systems already; all breaking up the data achieves is
to use up slightly more resources. If the data being sent is already
economically marginal, that may result in less data being sent --
but only a similar reduction to what you'd get if fees increased at a
similar rate. When the data storage use case is not economically marginal,
it will instead just result in less resources remaining available for
whatever monetary activity is still taking place.
As far as the "but contiguous data will be regulated more strictly"
argument goes; I don't think "your honour, my offensive content has
strings of 4d0802 every 520 bytes, and as they say: if the data doesn't
flow, you must let me go" is an argument that will fly. Having the data
be separated by longer strings or otherwise structured differently isn't
a bigger difference between an image in a bmp, a jpg, or one dumped
in a zip file or mime-encoded, and none of those will let you avoid a
regulator's ire.
Cheers,
aj
--
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/aN_u-xB2ogn2D834%40erisian.com.au.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-02 20:42 [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus PortlandHODL
` (4 preceding siblings ...)
2025-10-03 15:42 ` Anthony Towns
@ 2025-10-03 20:02 ` Luke Dashjr
2025-10-03 20:52 ` /dev /fd0
5 siblings, 1 reply; 19+ messages in thread
From: Luke Dashjr @ 2025-10-03 20:02 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 4620 bytes --]
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
> 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
> <https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubkeys.csv>
>
> 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%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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-ebcc778f57b0%40dashjr.org.
[-- Attachment #2: Type: text/html, Size: 6147 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
2025-10-03 20:02 ` Luke Dashjr
@ 2025-10-03 20:52 ` /dev /fd0
0 siblings, 0 replies; 19+ messages in thread
From: /dev /fd0 @ 2025-10-03 20:52 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5674 bytes --]
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–2 years 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 AM Luke Dashjr <luke@dashjr•org> 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 *
> - 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
> <https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubkeys.csv>
>
> 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%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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-ebcc778f57b0%40dashjr.org
> <https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALiT-Zo8wiZGCFeMwfd92zptw_cKz7ajMOjFWW%3DrdS9by3zYHQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7414 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread