MIME-Version: 1.0
References: <YjIqqv+0YTbl/fAL@petertodd.org>
 <159484190-6f2488890cf1a295d9a781253860f18d@pmq4v.m5r2.onet>
In-Reply-To: <159484190-6f2488890cf1a295d9a781253860f18d@pmq4v.m5r2.onet>
From: Kostas Karasavvas <kkarasavvas@gmail.com>
Date: Mon, 21 Mar 2022 13:00:38 +0200
Message-ID: <CABE6yHtBzbTP=CcsNrL2B9TrNchwWrhGZZtrFNsek4DCrpVv3g@mail.gmail.com>
To: vjudeu@gazeta.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bc939705dab86809"
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
Precedence: list

--000000000000bc939705dab86809
Content-Type: text/plain; charset="UTF-8"

Hi vjudeu,

There are use cases where your following assumption is wrong:  ".. and that
kind of data is useful only to the transaction maker."

No one really publishes the actual data with an OP_RETURN. They publish the
hash (typically merkle root) of that 1.5 GB of data. So the overhead is
just 32 bytes for arbitrarily large data sets. What you gain with these 32
bytes is that your hash is visible to anyone and they can verify it without
active participation of the hash publisher.

Regards,
Kostas


On Sat, Mar 19, 2022 at 9:26 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > 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@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
>

--000000000000bc939705dab86809
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi vjudeu,</div><div><br=
></div><div>There are use=C2=A0cases where your following assumption is wro=
ng:=C2=A0 &quot;.. and that kind of data is useful only to the transaction =
maker.&quot;</div><div><br></div><div>No one really publishes the actual da=
ta with an OP_RETURN. They publish the hash (typically merkle root) of that=
 1.5 GB of data. So the overhead is just 32 bytes for arbitrarily large dat=
a sets. What you gain with these 32 bytes is that your hash is visible to a=
nyone and they can verify it without active participation of the hash publi=
sher.=C2=A0</div><div><br></div><div>Regards,</div><div>Kostas</div><div><b=
r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Sat, Mar 19, 2022 at 9:26 PM vjudeu via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">&gt; 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.<br>
<br>
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).<br>
<br>
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)<br>
<br>
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 &quot;OP_RETUR=
N &lt;commitment&gt;&quot; with &quot;&lt;tweakedPublicKey&gt; &lt;tweakedT=
apBranchKey1&gt; &lt;tweakedTapBranchKey2&gt; &lt;tweakedTapBranchKey3&gt; =
... &lt;tweakedTapBranchKeyN&gt;&quot;. Then, we could use unspendable publ=
ic keys to push data, so OP_RETURN would be obsolete.<br>
<br>
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&#39;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 a=
ny new coins out of thin air, because everything would be merge-mined by de=
fault, 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 ea=
sily 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 d=
omains!<br>
<br>
On 2022-03-16 19:21:37 user Peter Todd &lt;<a href=3D"mailto:pete@petertodd=
.org" target=3D"_blank">pete@petertodd.org</a>&gt; wrote:<br>
&gt; On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev wrote=
:<br>
&gt; Since Taproot was activated, we no longer need separate OP_RETURN outp=
uts to be pushed on-chain. If we want to attach any data to a transaction, =
we can create &quot;OP_RETURN &lt;anything&gt;&quot; as a branch in the Tap=
Script. In this way, we can store that data off-chain and we can always pro=
ve that they are connected with some taproot address, that was pushed on-ch=
ain. Also, we can store more than 80 bytes for &quot;free&quot;, because no=
 such taproot branch will be ever pushed on-chain and used as an input. Tha=
t means we can use &quot;OP_RETURN &lt;1.5 GB of data&gt;&quot;, create som=
e address having that taproot branch, and later prove to anyone that such &=
quot;1.5 GB of data&quot; is connected with our taproot address.<br>
<br>
There are two use-cases for OP_RETURN: committing to data, and publishing d=
ata.<br>
Your proposal can only do the former, not the latter, and there are use-cas=
es<br>
for both.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div></div>

--000000000000bc939705dab86809--