pull down to refresh

192 sats \ 6 replies \ @SimpleStacker 1 May \ on: On relay policy and recent OP_RETURN drama - Antoine Poinsot bitcoin
The one thing I'm not really seeing in this article is what the benefit of expanding OP_RETURN limits are.
If people storing data in the witness script can do it more cheaply than having the data in OP_RETURN, why wouldn't they just continue to do that?
Many have taken the opportunity of my proposal to grandstand on Twitter. They exploit gullible people by making wild claims about OP_RETURN outputs being an existential threat to Bitcoin. I hope my post made it clear it is not, but consider also this. If Bitcoin was so brittle that Core choosing to relay perfectly safe, inexpensive to validate, consensus-valid transactions would break it, it would be utterly uninteresting in the first place!
The ability of this parasitical group to reach this level of attention is really telling of what our community values. I hope bitcoiners start demonstrating more critical thinking and stop giving in to the latest conspiracy theory every 6 months.
Woof.
write
preview
676 sats \ 3 replies \ @petertodd 1 May
The article explains the reason here:
It was recently brought to my attention that Citrea faced this situation with their Clementine bridge. In their construction, a watchtower challenge transaction needs to both pass on 144 bytes of data and be confirmed as soon as possible. Since they are restricted to a single 80 bytes OP_RETURN output by Bitcoin Core standardness, they use two unspendable Taproot outputs to include the other 64 bytes of data.
We're removing this limit rather than just raising it because we don't want to have to have this ridiculous discussion every time someone finds a new reason to use a little more.
reply
51 sats \ 0 replies \ @django 2 May
No Peter, this isn't valid reason. Critea is ZK rollup, aka they work on using bitcoin as data layer. Even just one glance at their main slogan "making it possible to build everything on Bitcoin" tells you just as much. The people who oppose relaxing op code limits are against this very idea and want bitcoin to be used purely as monetary system. They are justified with this example -- this is EXACTLY what they don't want.
Personally, I don't really have a strict opinion on this matter if I am honest, although I do observe what's happening to Ethereum, which not long ago advertised itself as "world's decentralised computer" (again, aka blockchain used for data). What bothers me though, how the bitcoin core devs are dealing with this drama (which stirs more drama). Even Antoine in the original article calls them "parasitic" ffs.
reply
10 sats \ 0 replies \ @SimpleStacker 1 May
Makes sense, thanks
reply
75 sats \ 0 replies \ @pycan 2 May
Why would we want to accommodate one company's needs on the blockchain level?
reply
0 sats \ 0 replies \ @endothermicdev 2 May
If people storing data in the witness script can do it more cheaply than having the data in OP_RETURN, why wouldn't they just continue to do that?
I would refer to Sjor's reasoning
I'm simplifying terribly, but I think the general issue is that putting the data in the witness makes syncing and validating the chain harder for future and current node operators. Validating each transaction requires checking it against all unspent transaction outputs from the entire blockchain (utxo set.) These have to be kept in memory by the nodes forever. If you can avoid having every node add to this with something that's in fact unspendable and only meant to record data, it makes validation quicker and nodes are cheaper to operate. It's a tragedy of the commons situation. Obviously the utxo set is going to grow regardless, but we might as well not encourage it to get worse by needlessly adding outputs that can never be removed.
reply
0 sats \ 0 replies \ @OneOneSeven 1 May
Yeah this is a question Ive had as well.
reply