Delivery-date: Fri, 03 Oct 2025 08:53:35 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of apoelstra@wpsoftware.net designates 66.183.0.127 as permitted sender) client-ip=66.183.0.127;
Date: Fri, 3 Oct 2025 14:59:32 +0000
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.
Message-ID: <aN_k1EAXZ0schWDs@mail.wpsoftware.net>
References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
 <842930fb-bede-408a-8380-776d4be4e094n@googlegroups.com>
 <aN_Wz5YbZ9NieQu0@mail.wpsoftware.net>
 <CALiT-ZpJ_F2UrvUwRjgMukxQJ+s8GVzgDCHWt=zMR+HkMDDWWQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rcEpZj59VSCFmsX4"
Content-Disposition: inline
In-Reply-To: <CALiT-ZpJ_F2UrvUwRjgMukxQJ+s8GVzgDCHWt=zMR+HkMDDWWQ@mail.gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--rcEpZj59VSCFmsX4
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

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.

--rcEpZj59VSCFmsX4
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmjf5NMACgkQxYjWPOQb
l8EohQf8Cw/cx5rEvND+8CA7JKizzW2/GR3R+GVLBOcUtrYo/4oAdFCTofox8pkP
0GSlKyYwTlwy+m3XB7Po2y5IPVO7pYbmXWtlV5jCuhvMWvkcLI6LANtBzeipDRlp
/Qjt40q9agGwV/ocwT+N3rR6gzPuymyrGrG6BVcrOmrUD4W+fF+rI/ZrGOOeOKJe
NFJCiDEaJY48b3T4vxd8cbBtX9wkc8i5FRBll8OgqmBw/q3q0PDGIoZxboRNLnNZ
f6ajS9MKJPhWf8lYZyci2X+Lu1AqHIJv703ya1lXTfj6WxeP5JHhuJXYiqnWEnqq
0eb7JN1F+EIG4Qci0iRjE2GETmubVA==
=Y0z8
-----END PGP SIGNATURE-----

--rcEpZj59VSCFmsX4--