> There are two use-cases for OP_RETURN: committing to data, and publishing > data. Your proposal can only do the former, not the latter, and there are > use-cases for both.
Only the former is needed. Pushing data on-chain is expensive and that kind of data is useful only to the transaction maker. Also, the latter can be pushed on a separate chain (or even a separate layer that is not a chain at all). Also note that since Taproot we have the latter: we can spend by TapScript and reveal some public key and tapbranches. It is possible to push more than 80 bytes in this way, so why direct OP_RETURN is needed, except for backward-compatibility? (for example in Segwit commitments) There is only one problem with spending by TapScript, when it comes to publishing data: only the first item is the public key. If we could use public keys instead of tapbranch hashes, we could literally replace "OP_RETURN <commitment>" with "<tweakedPublicKey> <tweakedTapBranchKey1> <tweakedTapBranchKey2> <tweakedTapBranchKey3> ... <tweakedTapBranchKeyN>". Then, we could use unspendable public keys to push data, so OP_RETURN would be obsolete. By the way, committing to data has a lot of use cases, for example the whole idea of NameCoin could be implemented on such OP_RETURN's. Instead of creating some special transaction upfront, people could place some hidden commitment and reveal that later. Then, there would be no need to produce any new coins out of thin air, because everything would be merge-mined by default, providing Bitcoin-level Proof of Work protection all the time, 24/7/365. Then, people could store that revealed commitments on their own chain, just to keep track of who owns which name. And then, that network could easily turn on and off all Bitcoin features as they please. Lightning Network on NameCoin? No problem, even the same satoshis could be used to pay for domains! On 2022-03-16 19:21:37 user Peter Todd <p...@petertodd.org> wrote: > On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev wrote: > Since Taproot was activated, we no longer need separate OP_RETURN outputs to > be pushed on-chain. If we want to attach any data to a transaction, we can > create "OP_RETURN <anything>" as a branch in the TapScript. In this way, we > can store that data off-chain and we can always prove that they are connected > with some taproot address, that was pushed on-chain. Also, we can store more > than 80 bytes for "free", because no such taproot branch will be ever pushed > on-chain and used as an input. That means we can use "OP_RETURN <1.5 GB of > data>", create some address having that taproot branch, and later prove to > anyone that such "1.5 GB of data" is connected with our taproot address. There are two use-cases for OP_RETURN: committing to data, and publishing data. Your proposal can only do the former, not the latter, and there are use-cases for both. -- https://petertodd.org 'peter'[:-1]@petertodd.org _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
