pull down to refresh
0 sats \ 0 replies \ @Murch 12h \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
We could:
- try to forbid the inscription envelope at the mempool level, which would probably lead to more nodes running less strict mempool policies, or more direct submissions to mining pools.
- soft fork out the inscription envelope specifically, but it would be trivial to come up with another similar construction that allows embedding data in the witness stack, and given the time line of soft forks, it would be hard to effectively ban new constructions that evade the soft fork rules. Some argue that being willing to ban the construction would be a sufficient signal for NFT activity to move to another network, but I am not convinced that this is true.
- soft fork in a much smaller limit on witness data, but that would simply increase the overhead for storing data, not actually prevent it.
- whitelist only single-sig payment output scripts, forbid all other scripts at the consensus level, but that would still allow people to embed data in fake pubkey hashes or fake pubkeys.
- whitelist only single-sig payment output scripts, and require that signatures prove that the scripts are spendable, but data could still be embedded by grinding signatures or stuffing them into transaction fields that hold arbitrary data like the input sequences.
Overall, it seems unfeasible that we make data payloads prohibitively expensive while payment transactions remain incredibly cheap. In the long run, small valuable payment transactions will outspend frivolous data transactions, and valuable data transactions will outspend valueless payment transactions.