Hi Antoine -
Thanks for engaging the community in what appears to be a good-faith effort to address its concerns.
I can’t speak for everyone who is against raising opreturn limits, but here are my thoughts:
First, it is possible to store data onchain in larger
OP_RETURNoutputs than allowed by Bitcoin Core standardness limits by using private bridges or alternative p2p relay networks.
Of course it is. This doesn’t mean the filters aren’t working. “Filters working” means that filters raise the cost of getting abusive transactions confirmed. The notion that filters don’t work because a transaction that pays 10x the normal rate occasionally slips through is a silly strawman. Spam filters have never been perfect; your email provider most likely filters spam, and I guarantee you are happy with keeping the filter even though an occasional spam email ends up in your inbox.
However, those require relying on a central point of failure or a not as robust p2p relay network. These may be acceptable options for people willing to store arbitrary data, but not for time-sensitive transactions as typically used by Bitcoin scaling solutions. Developers of such solutions want to be able to broadcast their time-sensitive transactions through the public network of Core nodes because of the robustness and censorship resistance guarantees it provides.
Bitcoin noderunners are not obligated to bend over backwards to accommodate dubious “scaling solutions” like Citrea. If they would like to be able to use our peer network to get their transactions confirmed in a timely manner, they can do what everyone else does and make their data fit into 80 bytes. If they cannot do this, then that’s not our problem; that’s their problem. If they go ahead and put their data into fake pubkeys, then they are using bitcoin in a way that users have not consented for it to be used, and should expect such transactions to be aggressively filtered.
In any case, the limit is not preventing those new applications from relaying their transactions through the public network. They just modify their transactions and use fake public keys instead. This method gives them standard transactions, but forces all Bitcoin users to store those outputs in the UTxO set forever because they are not spendable. This is why i suggested removing the limit, since they are going to store the data anyways just in a more harmful manner.
As I and many others have pointed out repeatedly, “save the utxoset” is a fake motivation. You are being dishonest here, and it would be great if you could come clean about what your real motivation is. Citrea’s abusive watchtower challenge transactions are expected never to occur. The worst-case scenario is a few hundred bytes per year. If you and other core devs pushing to remove opreturn limits really cared about utxoset bloat, you would lift a pinky to merge Luke’s anti-inscriptions PR which, if it had been merged at the time it was submitted, would have prevented the utxoset from tripling from 4GB to 12GB in the space of two years. Now we’re supposed to believe that suddenly core maintainers care about utxoset bloat because you’re worried about a few hundred bytes per year, when you still haven’t fixed the bug that allowed 8GB of new utxoset bloat (and might add another 8GB in the next two years)? Please forgive me for not taking this rationale seriously. Bitcoin users are sometimes dumb, but we’re not that dumb.
Raising the opreturn limit from 80 bytes to 100000 bytes is a cure 1000x worse than the disease it purports to solve (but does not actually solve). Sure, at the end of 2026 the utxoset might be an eensy-weensy bit smaller, but bitcoin will be overrun with shitcoin scams that crowd out real economic activity.
Therefore, the two are compatible. The limit does not prevent storing arbitrary data by relying on a third party. The limit does prevent applications from storing data through
OP_RETURNs and also use the public relay network. Therefore the applications turn to still relaying through the public network, but to do so they use a more harmful way of storing the data thanOP_RETURNoutputs (namely, unspendable outputs).
Again, this is Citrea’s problem, not the bitcoin network’s problem. If they can’t find a way to build their application in a way that bitcoin users consent to (ie, by fitting their arb data into 80 bytes), then they should build on a different blockchain, or build something else. It is not up to bitcoiners to accommodate random VC-funded scamcoin rollups.
What we believe an application may or may not need is irrelevant
No it isn’t. Bitcoin is money, and should be used as such. It should not be used as a [practically-]free-forever personal file storage service. Bitcoin should not cater to non-monetary usages, because it will quickly be overrun by scams and crowd out real economic activity from honest merchants just trying to start a Lightning node.
If an application fits its arbitrary data into 80 bytes, then it can do whatever it likes, as long as it doesn’t crowd out legitimate economic activity (Runes are a notable exception, where their data fits into 40 bytes but crowds out legitimate activity). If it doesn’t, then it needs the bitcoin user network’s consent. Citrea has not gotten our consent and has not even asked for it. This is a hostile action, no matter how you spin it. We should not be kowtowing to scammers who threaten to harm bitcoin, by giving them whatever they want. This is a surefire way for bitcoin to become irrelevant in short order.
I would personally disagree that a zero-knowledge proof (in the case of Citrea) for a Bitcoin scaling solution is “spam”.
I agree that it’s not that harmful and we should not make any changes to the protocol, except socially ostracize Citrea and anyone involved. It is only fair that if you treat bitcoin with hostility, bitcoiners should treat you accordingly.
Now, what is qualified as “spam” does end up in the chain anyways.
This is not relevant. The vast majority of potential spam never happens, because there are filters in place that reduce economic demand for such transactions, so people either make their transactions fit into bitcoin’s mempool policy, or they spam other chains. Yes, occasionally a spammer will put his transaction into the chain by relaying it directly to a miner, but this is usually very costly because of robust mempool filtering.
Preventing “public key stuffing” is not on the table
I have no idea why anyone would think this. Luke-jr gave a workshop at bitcoin++ demonstrating how to filter Citrea’s watchtower challenge transactions. As long as the transaction format is known (and it must be known in order for anyone to use the spammy metaprotocol), a filter that blocks it can trivially be made. Yes, Citrea could have been more sneaky about hiding their data, but we can just make a filter that blocks that, too. If Citrea treats us with hostility, we can trivially make it so their whole protocol falls apart because these watchtower transactions don’t quickly confirm. It will not be easy for hostile VC-funded apps like Citrea to get investor funding in the first place unless they work with us instead of forcing their apps on bitcoin users.
People won’t move from using fake pubkeys to op_return to be nice to us is ludicrous because it’d cost them 4x more. This is just bluff to kill the filters.
Yes, it’s incorrect that opreturn is 4x more expensive than fake pubkeys, but it’s not incorrect in that it’s silly to expect hostile companies like Citrea to simply rewrite their protocol to use opreturns because they’re “good citizens” or something. They’ve literally just proven that they are the opposite. If they said “hey bitcoin community, we’re building something we think is really important for bitcoin and will benefit the ecosystem a lot, would you consider raising the opreturn limit to 145 bytes?”, then that would not have caused such a backlash. The reason they didn’t do it is probably because they are not confident their product would be useful to bitcoin in any way, so they knew it would be a tough sell. (I’m certainly not convinced.) So they went the sneaky backdoor way instead.
This is why we need to act now, to make the less harmful option available before such applications are deployed.
No, we really don’t. Again, persuade bitcoiners that what you’re doing is going to impact us positively. If you can’t do this, then go away! (Ethereum is right there!)
Transactions can already carry large payloads of data. Transactions pay a fee once, regardless of how long they are stored. Transactions are always stored forever by unpruned nodes. The proposed change does not affect this.
What this ignores is that non-arbitrary data (data relevant to utxo transfer) is priceless to the bitcoin network because it is always relevant forever, because new nodes will always need to sync the blockchain from genesis in order to fully join the network. This is why we store utxo-ownership-transfer-relevant data for the rest of eternity - because if we didn’t, bitcoin would simply not function. So there’s a huge cost to storing this data, but also a huge benefit.
Conversely, arbitrary data carries no such benefit. It is forgotten almost immediately. In ten, or a hundred, or a million years, everyone you know will be dead, and all nuclear waste will be safely broken down, but everyone’s brc20 scamtokens will still be in the blockchain. The differential benefits between arbitrary data and non-arbitrary data are incalculably massive, so we must bias bitcoin toward non-arbitrary data, so bitcoin doesn’t collect so much garbage that it collapses under its own weight.
Relaying larger
OP_RETURNoutputs on the public network may marginally reduce the cost of using them. However the data stored inOP_RETURNoutputs cost 4 times as much as data stuffed in an input witness, which is standard today and already relayed on the public network.
Yes, and this is a bug that should be fixed. The bitcoin network has agreed to 80 bytes of arbitrary data per transaction. Inscriptions larger than that do not have the consent of the bitcoin network.
Boiling frog: Core developers are trying to gradually make Bitcoin a universal database instead of just money, one step at a time.
I don’t think there’s any such conspiracy, but I do think the economic incentives created by fiat money push all truly disruptive movements eventually towards watering down and irrelevance. It’s hard to think of a better way to do this to bitcoin than to have bitcoiners forget that bitcoin is money, and instead convince them that it’s a database with no particular purpose.
Core is trying to accommodate the Taproot Wizards who are a self-declared attack on Bitcoin which tries to corrupt the ecosystem.
Are Taproot Wizards and Citrea linked? I wasn’t aware.
Anyway I already addressed this; I don’t think the accommodation is necessarily intentional on the part of core devs; I just think that core devs are no longer willing to act with courage and tell companies with large VC-funded purses to get lost.
Raising UTxO bloat as a concern is ironic when considering applications like Citrea may only cause trivial amount of bloat while inscriptions, which Core refuses to filter, are responsible for over 8 GiB of bloat in the past couple of years.
This is confusing UTxO set usage and UTxO set bloat. While there is no normative language for Bitcoin concepts, the latter usually refers to forever unspendable outputs. No matter what we do those outputs will sit forever in every single user’s UTxO set. Spendable outputs, even if uneconomical to spend, can always be swept by someone incentivized out of band or a good samaritan (as was done in the past).
Are you hearing yourself right now? You’re not seriously trying to argue that 8GB of new utxoset bloat, created by brc20s that are NEVER, EVER going to be spent, are somehow less harmful than Citrea’s “definitely unspendable” fake pubkeys, even though such txs have caused precisely 0 bloat so far, and are not expected to cause more than a few hundred bytes per year?? Come on, man, stop being silly.
Utxoset bloat appears to have been fixed in libbitcoin’s most recent unreleased version anyway, so I’m much less concerned by utxoset bloat, and much more concerned by high-fee spam that crowds out legitimate spends, which is what removing the opreturn limits will DEFINITELY incentivize.
Anyway, I don’t have the time or inclination to respond to your whole post, but I think the above suffices to communicate my understanding of the opposition to removing the opreturn limits.