📅 Original date posted:2022-03-19
📝 Original message:> 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 <pete at 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
vjudeu at gazeta.pl [ARCHIVE] /
npub135…nssga
2023-06-07 23:06:30
in reply to nevent1q…um0w
Author Public Key
npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssgaPublished at
2023-06-07 23:06:30Event JSON
{
"id": "f7b043873b741fd4d73b49b595b6470b36a4e040a07bec2b75340174c0036d54",
"pubkey": "8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32",
"created_at": 1686179190,
"kind": 1,
"tags": [
[
"e",
"eb152f6102d6aecd645f09865b06cdcb41dafdb1f68ba80a6cdd71f7aea8b4bc",
"",
"root"
],
[
"e",
"9436c7c1f2f1eba90f789ec6a87fee31cba397939ce7829e04470aedecba3cd7",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-03-19\n📝 Original message:\u003e 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.\n\nOnly 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).\n\nAlso 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)\n\nThere 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 \u003ccommitment\u003e\" with \"\u003ctweakedPublicKey\u003e \u003ctweakedTapBranchKey1\u003e \u003ctweakedTapBranchKey2\u003e \u003ctweakedTapBranchKey3\u003e ... \u003ctweakedTapBranchKeyN\u003e\". Then, we could use unspendable public keys to push data, so OP_RETURN would be obsolete.\n\nBy 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!\n\nOn 2022-03-16 19:21:37 user Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev wrote:\n\u003e 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 \u003canything\u003e\" 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 \u003c1.5 GB of data\u003e\", 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.\n\nThere are two use-cases for OP_RETURN: committing to data, and publishing data.\nYour proposal can only do the former, not the latter, and there are use-cases\nfor both.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org",
"sig": "b526db471cff5cb8f57487221a06a447649ba478a06e1ca6bf2cb2977968c7e21011d6bc350be0d01fb6a51201dd4af195e4d12540daf491f73153abd8da1629"
}