pull down to refresh
257 sats \ 9 replies \ @tidwell OP 4 May \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
A similar PR was proposed by Peter Todd 2 years ago, why was it rejected then? What has changed since then, why would this get approved now?
For the record, this pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits. And yes, that's the thing that has changed since.
reply
With all due respect, and I mean this totally neutrally...
Is there any way to get Citrea to just stop? Like hey, 'cut it out'?
Some of the criticisms I've heard are specifically that one company wants to make use of larger op_return data fields... so why change mempool policy for one company specifically? What if another company in the future wants to do something else, even if in the spirit of harm reduction, should we change mempool policy just for a company to play defi?
Another question: how many unprunable outputs are we talking about from Citrea? Hundreds? Thousands? Tens of thousands? Is this something really core to their business model? Is there any other way of them doing what they want to do, without requiring such a change? How polluting would they (or the others to follow them) really be for the network?
Finally, since LibreRelay works with only a limited number of nodes in the network available... why don't they just use LibreRelay? That way they could have larger op_returns without necessitating unprunable outputs.
THANK YOU
reply
Why do you want them to stop?
They want to use Bitcoin and make an L2 on top of it.
No there is no way to make them stop with the current consensus rules and it's deeply pathological to even suggest such a thing. Bitcoin is supposed to be censorship resistant.
Another question: how many unprunable outputs are we talking about from Citrea? Hundreds? Thousands? Tens of thousands? Is this something really core to their business model
They need two taproot outputs to embed an extra 32bytes * 2 in.
So in total they're embedding 144 bytes of data.
This is also in the worst-case scenario that's never supposed to happen, where the bridge is malfunctioning.
In normal operation there won't be any data embedding here.
reply
Is there any way to get Citrea to just stop? Like hey, 'cut it out'?
In this particular case, definitely not. Even with the "prove your bytes aren't arbitrary data" soft fork proposal they're doing something valuable enough to make grinding bytes feasible.
why don't they just use LibreRelay?
Because this type of Citrea transaction is time sensitive. Only two major mining pools mine oversized OP_Returns right now. That means there's a decent chance this type of Citrea transaction – a tx that responds to fraud – would fail to be mined.
deleted by author
Why wouldn't the core dev open this themself?
reply