Nostr Web Client

I was not trying to propose a way forward in that regard to be honest, but I bring it up in relation to the removal of the 80 bytes limits.

I don't think It can be argued that lifting the OP_RETURN limit serves the purpose of mining decentralization thanks to a leaner UTXO set, precisely because of it being more expensive to embed larger arbitrary data in outputs.

Historical developments in Bitcoin Core make me suspicious of the argument that OP_RETURN should have no limits in order to protect the UTXO set. Had this been the goal, Core devs would have tried to somehow contain the effects of ordinals. Since this didn't happen, I can only conclude that v30 is removing this relay policy fllter for other reasons which I do not at this point understand.

With regards to mining decentralization, I think the community should focus its time and energy on StratumV2, but this entails talking to miners and convincing them of the benefits of block template selection etc etc

SatsAndSports 3mo ago

> Core devs would have tried to somehow contain the effects of ordinals

Be practical. What do you mean here?

Do you mean a fork should have been rushed out to make ordinals non-consensus-valid? If yes, how do you define an 'ordinal'? For the most part, those transactions looked like normal (Taproot) transactions.

In fact, the 'epic ordinals' are simply the first satoshi mined after each halving.

In order to filter out the epic ordinals, *you would have to filter out the coinbase transaction after each halving*!

If you research ordinals, you'll realise there was no quick fix. And even if there was, it's not responsible to rush out a node upgrade every week to try to squash the latest silly hack. It was somewhat obvious that ordinals (and NFTs and so on) were just fads

> Core devs would have tried to somehow contain the effects of ordinals. Since this didn't happen, I can only conclude ....

It *could* be an evil Core-munist conspiracy. Or it could be that the topic of Ordinals requires more subtle thought ...

(Epic ordinals, and other ordinal stuff, are discussed in detail here: https://www.nervos.org/knowledge-base/guide_to_inscriptions)

Reply to this note

Please Login to reply.

Discussion

epsql 3mo ago

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/

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.