From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: /dev /fd0 <alicexbtong@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Date: Fri, 3 Oct 2025 14:59:32 +0000 [thread overview]
Message-ID: <aN_k1EAXZ0schWDs@mail.wpsoftware.net> (raw)
In-Reply-To: <CALiT-ZpJ_F2UrvUwRjgMukxQJ+s8GVzgDCHWt=zMR+HkMDDWWQ@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2025-10-03 15:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 20:42 [bitcoindev] " 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-03 7:11 ` Garlo Nicon
2025-10-02 22:27 ` Brandon Black
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
2025-10-03 14:18 ` /dev /fd0
2025-10-03 14:59 ` Andrew Poelstra [this message]
2025-10-03 16:15 ` Anthony Towns
2025-10-03 13:21 ` [bitcoindev] " 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
2025-10-03 20:52 ` /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aN_k1EAXZ0schWDs@mail.wpsoftware.net \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=alicexbtong@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox