This seemed worth clarifying, so I did the thing where I ask a question and answer it myself:
Discussion
I think the much better question is why would somebody use OP_RETURN for stamps, BRC-20 and Counterparty. It does make a difference for some of these protocols if the data is in an output, or the scriptsig, or witness part of a transaction.
With stamps the explicit goal was to bloat the UTXO set. Their marketing framed that as "unprunable".
Counterparty was designed before SegWit and due to fee spikes around that time was pretty much unmaintained afaik.
BRC-20 is just crazy. JK, I have no idea how that one works.
Stamps use CounterParty under the hood, which simply switches to bare multisig once the payload goes over 80 bytes. With the proposed Bitcoin Core change to policy, or just considering relay reality, CounterParty could stop doing that. But afaik nobody is maintaining it, and the inefficiency is a feature for some of its users (stamps).
You're right, those are in another class altogether. Upvoted your post and answer fwiw :)
Hi Sjors, appreciate your explanation, but which 'protocols' do you address here (below)? I mean, Lightning needed a softfork, we tacked on some privacy improvements later, but I'm unaware of other high prio things still being addressed... And if applications need data before spending, why not out of band, like miniscript? I'm very new to this discussion, but insiders that can clarify things to educate are hard to find while there's so much noise...
"Some protocols require certain data to be available before the transaction is spent. Since the witness is only revealed at spending time, it would be too late."
The Stack Exchange post links to the mailinglist post by Antoine Poinsot. It it turn uses Citrea as the example. They use some sort of watch-tower scheme that needs to look for zero-knowledge proofs on chain and then react.
And from that I'm assuming various BitVM schemes will work in similar ways. Hard to predict what ends up being successful here.
Okay, thanks. I was pretty much in the 'let's ossify except for bug fixing and unforeseen future needs, cut off all feature discussions and level up with focus on 2nd layers with a stable base' camp.
This adds to that conviction.
I hope we get there asap.
Clarity - hard to achieve in an open source world...
One way to look at OP_RETURN usage by "L2" projects, is to get a sense of what future op codes could look like. If people keep sticking zero knowledge proofs there, maybe at some it makes sense to just add a zero knowledge proof output type. Obviously that's a _very_ long time out, and there might be very good reasons to never do it. But you can look at it as a (permissionless) draft.
This also illustrates that if we had made this change earlier, they would not have designed the system to create unspendable public keys in the first place.
They have no financial incentive to deviate from the original design. And once such a system goes live, assuming it has any uptake, their engineers will be busy with all sorts of more urgent things.
Any typical corporate CTO would look at this situation and say: hey look, there's a bunch of drama here, let's assume the brigaders win and the OP_RETURN limit stays in place. So let's just stick to the original design. We're not price sensitive, so it's the safest option. It also saves us a bunch of engineering hours. Also, it protects our engineers from being harassed.
Finally, this also goes to show that we really need to make progress on Utreexo, because UTXO set growth is a sitting duck. All we can do is ask people nicely to not grow it needlessly.
What’s the status on Utreexo these days? It seemed like a cool project but I never see any mention of it these days.
Looks like there's a beta? https://bitcoinops.org/en/topics/utreexo/
nostr:nprofile1qqswpna42jwnea7mfcnnd78phjz0vfyx4aayz22ase7x5vf5tyzz22qpzamhxue69uhkummnw3ezuervwdhh27np9ekx7mqjpsjlm may have some information
We have specs for the accumulator and basic p2p stuff. Working on cache rn. We should have something public soon.
We also have:
A Golang lib at https://github.com/utreexo/utreexo
A rust lib at https://github.com/mit-dci/rustreexo
And two implementations of the bitcoin consensus that uses utreexo:
Utreexod: https://github.com/utreexo/utreexo
Floresta: https://github.com/vinteumorg/floresta
Hi,I've got some exciting news for you,I can teach you how to turn your $300 into $9500 in just 4hours investing Bitcoin mining without interrupting your daily activities.
DM ME HOW FOR MORE INFO: 📞
WHATSAPP: +1 (818) 463‑4473
Email:
christineduff300@gmail.com
Telegram Username: christine4219
It's easier for a light client to obtain data in an OP_RETURN too - you only need the block merkle root, for witness data you'd need to get the coinbase tx and the witness commitment as well.
My very limited understanding of Citrea is that it implements such a light client in BitVM.