Delivery-date: Fri, 03 Oct 2025 08:54:11 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193;
Date: Sat, 4 Oct 2025 01:42:51 +1000
From: Anthony Towns <aj@erisian.com.au>
To: PortlandHODL <admin@qrsnap.io>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Message-ID: <aN_u-xB2ogn2D834@erisian.com.au>
References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
X-Spam_score: -0.0
X-Spam_bar: /
X-Original-Sender: aj@erisian.com.au
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as
 permitted sender) smtp.mailfrom=aj@erisian.com.au
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.8 (/)

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.