pull down to refresh

676 sats \ 3 replies \ @petertodd 1 May \ parent \ on: On relay policy and recent OP_RETURN drama - Antoine Poinsot bitcoin
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.
write
preview
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