Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <YjIqqv+0YTbl/fAL@petertodd.org>
Date: Sat, 19 Mar 2022 19:32:00 +0100
Message-Id: <159484190-6f2488890cf1a295d9a781253860f18d@pmq4v.m5r2.onet>
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
Precedence: list

> 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 p=
ushed 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 tha=
n 80 bytes in this way, so why direct OP_RETURN is needed, except for backw=
ard-compatibility? (for example in Segwit commitments)

There is only one problem with spending by TapScript, when it comes to publ=
ishing 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 <co=
mmitment>" with "<tweakedPublicKey> <tweakedTapBranchKey1> <tweakedTapBranc=
hKey2> <tweakedTapBranchKey3> ... <tweakedTapBranchKeyN>". Then, we could u=
se 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 whol=
e idea of NameCoin could be implemented on such OP_RETURN's. Instead of cre=
ating some special transaction upfront, people could place some hidden comm=
itment and reveal that later. Then, there would be no need to produce any n=
ew coins out of thin air, because everything would be merge-mined by defaul=
t, providing Bitcoin-level Proof of Work protection all the time, 24/7/365.=
 Then, people could store that revealed commitments on their own chain, jus=
t 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 domai=
ns!

On 2022-03-16 19:21:37 user Peter Todd <pete@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 co=
nnected with some taproot address, that was pushed on-chain. Also, we can s=
tore 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 lat=
er 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 d=
ata.
Your proposal can only do the former, not the latter, and there are use-cas=
es
for both.

-- =

https://petertodd.org 'peter'[:-1]@petertodd.org