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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aN_u-xB2ogn2D834%40erisian.com.au.
