pull down to refresh
0 sats \ 3 replies \ @HardRich 11 Jun \ on: Influencers out in Storm: Is *This* the Hill to Die On? bitcoin
Do you know what the benefits from removing op_return are other than more jpeg storage? Are there any downsides to leaving things as is?
I’ve heard the argument is to limit spam. But is there a benefit removing op_return or a downside by leaving it?
The spam relative to having it in the witness, is 4x as expensive when in op_return (that's my understanding at least). 4mb of data can be in the witness. A total of 1mb of data can be in the op_return (as a part of the transaction) so op_return spam is by definition smaller, more expensive, and far more limited than when included in witness.
My understanding is that Casey Rod's 'inscription' method requires 2 transactions to 'publish' the data (in witness) but that may not be the case for jpegs/nfts in op_return so the number of 'transactions' is less overall. (That's why Casey R created Runes which use op_return instead of Witness... they are a less spammy version of memecoins).
If all the 'jpegs' were instead put in op_return we would have fewer of them, more compact blocks, and the 'spam' would in general be more expensive for the same size and content.
My understanding is that certain actors are using fake public keys to add data to the chain but those UTXOs are unspendable/very bloating. Op_return outputs are unspendable/can be pruned so don't bloat the UTXO set which is the most harmful aspect of any of the spam.
In addition my understanding is that from an engineering perspective... it's just 'cleaner' and 'neater' to use op_return for arbitrary data (which is what some people seem to want) rather than witness or fake keys. So it's better from an engineered perspective... but I don't know enough to speak to that that's just what I've read...
reply
Mostly right, a few comments:
- The overhead to publishing data in an Inscription is bigger because you first have to make a commitment in the output and then create a P2TR scriptpath spend to reveal the inscription. After paying for that, the data is subject to the witness discount, so the data bytes only weigh one 1 weight unit. OP_RETURN outputs are not subject to the witness discount, so they weigh 4 weight units, but they have less overhead. So, smaller data payloads are slightly less expensive to be published in OP_RETURN than in Inscriptions, larger data payloads are cheaper to publish in Inscriptions. The border between the two is around 144 bytes. So, this change would make it slightly cheaper to publish data payloads of up to 144 bytes, and make no difference for larger payloads as they would continue to be published as inscriptions, assuming the sender optimizes for cost.
- Since hashes and public keys mostly look like random data, people have been using them to publish very small chunks of data since pretty much forever. Such payment outputs cannot be discarded, because they are theoretically spendable, and if one were spent, it would split the network between nodes that accept the transaction and those that do not. Therefore they are permanent additions to the UTXO set, which represents the minimal state that every full node must retain to validate transactions. For extremely small data amounts, the overhead of fake payment outputs is similar to OP_RETURN outputs, but it’s slightly more expensive. By dropping the limit on OP_RETURN outputs, it is always be cheaper to publish data into an OP_RETURN than to publish it into a fake payment output. OP_RETURN outputs do not need to be stored in the UTXO set, because they are provably unspendable.
reply
Thank you for the clarification
reply