Nostr Web Client

I was implicitly referring to inscriptions when mentioning ordinals, sorry for the confusion here. What I meant is that when inscriptions became a thing and the PR to filter them was proposed by luke-jr by matching against OP_FALSE OP_IF, why did not Core propose relaxing the OP_RETURN limits then? I'd expect that to have been the rational thing to do given the arguments with respect to UTXO set bloat

I don't think there is any conspiracy on the part of Core, and I appreciate that filtering spam is not some easy task to be carried out over the weekend, but I don't understand the timing for this proposal, unless this is entirely explained by Citrea as its catalyst.

SatsAndSports 3mo ago

> unless this is entirely explained by Citrea as its catalyst.

You say this as if it's some evil conspiracy

Even though I keep hearing about Citrea, it's difficult to get people to speak factually and with evidence. I've included a screenshot of what appears (after my limited research) to be the link between Citrea and OP_RETURN

We can't just magic away usages of Bitcoin that we don't like. From what I can see, Citrea will either use a large OP_RETURN, or a small OP_RETURN combined with two unspendable outputs. I don't think we can block them from both options; the most we can do is nudge them towards the one that we find less harmful

When relays are strict about filtering, then it means that Citrea will either use unspendable outputs (increasing the size of the UTXO sets) or will pay large miners out-of-band for large OP_RETURNs. Both of those are bad for miner centralization

Again, be practical, and share practical plans and alternatives, bearing in mind that some of us put miner decentralization very high on the list of priorities. Spreading paranoia about complex systems isn't helping anybody

https://blockspace.media/insight/everything-you-need-to-know-about-the-op_return-data-limit-debate/

Reply to this note

Please Login to reply.

Discussion

epsql 3mo ago

> You say this as if it's some evil conspiracy

I really am not, in fact I welcome developments such as Citrea and Strata by Alpen Labs. I mentioned Citrea in relation to my other point, which is that I don't understand the timing of this relaxation in relay policy.

Given that preventing the UTXO set from increasing is one of the goals, I am trying to understand how come OP_RETURN limits were not dropped in 2023 when inscriptions were rapidly increasing the UXTO set. Things are complex and I understand that there is not necessarily an answer here, but I am far from suggesting that something shady is going on behind the scenes as an attempt to overthrow Bitcoin or other such things

SatsAndSports 3mo ago

Thanks for your quick response, and also for being constructive

I think I'm getting tired of other people and their conspiracies, and therefore I'm quick to assume (incorrectly sometimes) that everybody is being irrational.

[I love conspiracies sometimes, and Bitcoin is too important to be based on naivete. We should verify, not trust]

Anyway, to return to the topic:

Inscriptions require *two* transactions usually (or maybe always). Witness data can be attached only to inputs, not outputs. So, in order to attach some witness data (indirectly) on an output, you have to have a second transaction - taking that output as an input - and then attaching the witness data to the second transaction.

I mention this complexity because it might have been another factor in the topic. The Inscriptions folks might have been willing to do this. But maybe more recent use cases require a single-transaction approach and therefore the witness data is unusable and therefore the choice is between a large op_return or unspendable outputs.

[Again, I might be missing some details here. I think I know a lot of these details, but I'm kinda inferring things from multiple different blog posts. I would be happier if a really high quality document about all of this already existed]

My guess is that the truth is something like this: Witness data is the cheapest way to get arbitrary data in the block. But, as it requires two transactions - not just one - it is sometimes impossible for certain use cases. The single-transaction use cases therefore have to choose between a large op_return and unspendable outputs. Reluctantly, in this case we must large op_returns in the mempool if we are serious about miner decentralization.