path: root/bb/7fbb4a4da3dadeeb7a046300a02c9c001c1fa4

Return-Path: <kkarasavvas@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B72A3C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 11:00:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B316D405B1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 11:00:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6NIl9AzzZ1NR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 11:00:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com
 [IPv6:2607:f8b0:4864:20::633])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3FAED40535
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 11:00:50 +0000 (UTC)
Received: by mail-pl1-x633.google.com with SMTP id k6so5220197plg.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 04:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=J9oWbv+GZYxw7FJEPS9P0ms92vuIFuf+nI2uBIK+xj4=;
 b=cj1wOzEy8CaqelYJcdFI/j/Yr14LtvuAaOejfEwPmrPhGcLhFNBYUAUVr1sSp8dOw4
 6MCwTxjVqMigLRv0wrJSlvZw92vL2s1os+048qX7SMhcXg1jNrhyqdjdMDjkJVbk1Fnk
 Ulw4Gb4s7mjqZiwhKWY8fnUq/dPhBIn52YNnoIRS8IThJLhpG94pbcEup4jElvUtCvLl
 AtzLW1EDTP3S0CJgmSVArM8u0i3sL9J4Xe12/eYU/FZGZoNt1mWe6Z+w/IYG8eExlIQ6
 i+SM2ygYwVzXFOeEYms+g9gnHsYtKpp+GkNrdAGkb1Sq/ne5yuYCYE2oWBadZBSB/KUZ
 ziGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=J9oWbv+GZYxw7FJEPS9P0ms92vuIFuf+nI2uBIK+xj4=;
 b=itbuuccjLXgujOBlMmk0tFUQXE8pl+eV/Y2cOl0M5FEEEK4si9NqpvjjdqdCH+GpUT
 w+e6la1VG1Vgs9HnUxGihVitZciHJ3VMxvrdQjCOQkq9HI6hLMso43rgpvYQby/zrk2j
 xVnonJQwzoNDT3YXGmludn0hvmz4+ysR3vkZBVxB2zZOFSWMpRV60SNpy4FeMmZLLgfK
 AQRZC43Br5x2kpKZvt3+/W/Tcpkgf+Aa8GKLIuPif/TDL8j+3OPFIgNdXHT5wLUEaSiR
 zaFT5QZMwd+E/AYwcZ2p3snmd4ndE+BVdFfq8PFnDbxNx1m7m8ZLC8DcZurUdV2vX44K
 9OEw==
X-Gm-Message-State: AOAM530Fktl3ZbmhEMm2MiriT9BMSrNIltSFjw5jrOqu2N6zJOO9zXE3
 9Z7EOV3Cnn1Sf7XTDCt2RJNWlNb1iysREBPpUa99lgmZHj8=
X-Google-Smtp-Source: ABdhPJxC78HX5IeGatSNHwBVTKkwd88oquFLiOmFr9qBc5nhTW6iWIBieMn3f4QNl5a2Lv2PaT6GDueFhGwjWXicjA4=
X-Received: by 2002:a17:902:654d:b0:153:be61:dfcd with SMTP id
 d13-20020a170902654d00b00153be61dfcdmr12005423pln.108.1647860449578; Mon, 21
 Mar 2022 04:00:49 -0700 (PDT)
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"
X-Mailman-Approved-At: Mon, 21 Mar 2022 11:40:15 +0000
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 11:00:51 -0000

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