Donβt think there is a valid use case for greater than 80 byte op returns? What about storing your multisig wallet descriptor?
This really blurs the lines between spam and bitcoin related. Strictly speaking, storing such data is spam because no node needs this data to verify transactions. But such descriptors contain info that is 100% needed by your wallet to spend your coins (although descriptors are not maximally data size efficient, especially since you should have keys backed up separately anyhow).
@Peter Todd
Login to reply
Replies (13)
interesting idea
You can store the Hash
It is only 32 bytes
There is no reason to have a 100K OP_Return
You donβt even need 32 bytes to store the essential info for the simplest casesβ¦but storing the hash is not a backup method though either.
Why do you need to backup your wallet on chain to begin with? Doesnβt even make any sense.
Just encrypt it and store the hash if you must.
Letβs go to a trillion bytes to address that? No?
This is a nonsensical comment in this context. But I totally agree with you.
For more nuance, jump to the bottom here and have a look at the technical side of this rather emotionally charged argument.
H/t @David A. Harding I believe for these optech newsletters?

Bitcoin Optech
Bitcoin Optech Newsletter #373
This weekβs newsletter summarizes a vulnerability affecting old versions of Eclair and summarizes research into full node feerate settings. Also ...
I was kidding about 1 trillion bytes, but 100k is orders of magnitude greater than where we are currently and I hope you see that pointβ¦.
There has been no cogent argument to necessitate any change that would mandate V30 and blow open op returnβ¦β¦.
There is no impending functionality issue with #Bitcoin that would necessitate this, and if there is please point it out to meβ¦β¦..
Full disclosure:
I am cool with old versions of Core and current version of Knots
checkout the proposed "Compact encryption scheme for non-seed wallet data" BIP, it's a good example of this idea:

GitHub
Bip draft: Bitcoin Encrypted Backup by pythcoiner Β· Pull Request #1951 Β· bitcoin/bips
This is a bip for encrypted backup, an encryption scheme for bitcoin wallet related metadata.
Mailing list post: https://groups.google.com/g/bitcoi...
Finding more excuses to expand opreturns.
Also check out what Josh has proposed and written code to support here:

Delving Bitcoin
A simple backup scheme for wallet accounts
Hey @salvatoshi, I created a rust library descriptor-encrypt that can encrypt any descriptor such that only authorized spenders can decrypt. I plan...
cc: @Josh Doman
A better reply would have been for you to opine on whether storing wallet descriptor data on chain is spam or notβ¦my gut says it feels like spam because itβs not data used in transaction validation but itβs not the worst of spam because it leverages bitcoin blockchain immutability and availability to bring value to the bitcoin stored in the wallet. Maybe thatβs a stretch. I dunnoβ¦
I donβt understand why going from close to zero op return limit to as much as you can possibly stuff in there in one jump is being proposedβ¦other than avoiding to have to deal with the issue again and again and again for decades.
There is a very clear and compelling argument as to why in the final steady state of a successful bitcoin blockchain the decentralized censorship resistant network must relay all valid transactions to minersβ¦the logic is a few steps long but the rationale is accessible.