Author: vjudeu at gazeta.pl 2022-03-19 18:32:00
Published on: 2022-03-19T18:32:00+00:00
The context explains that there are two use-cases for OP_RETURN which are committing to data and publishing data. The former is needed while the latter is expensive and useful only for the transaction maker. Since Taproot, it's possible to spend by TapScript and reveal some public key and tapbranches. This way, pushing more than 80 bytes is possible, and there is no need for direct OP_RETURN except for backward compatibility. However, there is only one problem with spending by TapScript when it comes to publishing data. Only the first item is the public key, and if we could use public keys instead of tapbranch hashes, we could replace "OP_RETURN" with "..." and use unspendable public keys to push data, making OP_RETURN obsolete. Committing to data has many use cases, such as implementing the whole idea of NameCoin on such OP_RETURNs. People could place hidden commitments and reveal them later, eliminating the need to create a special transaction upfront. Everything would be merge-mined by default, providing Bitcoin-level Proof of Work protection all the time, 24/7/365. The network could store revealed commitments on their chain to keep track of who owns which name. Additionally, that network could easily turn on and off all Bitcoin features as they please, including using the same satoshis to pay for domains. On March 16, 2022, user Peter Todd responded to a proposal stating that while the proposal could do the former use-case of committing to data, it cannot do the latter of publishing data, which has its own use cases.
Updated on: 2023-06-15T17:15:07.236339+00:00