pull down to refresh
300 sats \ 1 reply \ @Murch 11 Jun \ parent \ on: Influencers out in Storm: Is *This* the Hill to Die On? bitcoin
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.
Thank you for the clarification
reply