path: root/cf/daee6ce543311c921a24c227a8872f637c88b2

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 53F7DC0011
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 13:27:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 3B43A416BF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 13:27:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.854
X-Spam-Level: 
X-Spam-Status: No, score=-0.854 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, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H5=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0Qks8GH3jGTz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 13:27:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo104.poczta.onet.pl (smtpo104.poczta.onet.pl
 [213.180.149.157])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 99D044168F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 13:27:27 +0000 (UTC)
Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4K4DGc0cj3z1mkZ;
 Thu, 24 Feb 2022 14:27:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1645709240; bh=Uc+wXJpXbKOe8D1HlDQklzW77F06/BTpC01jNQ86aTQ=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=ZVNPXjt3irUhWSHK1eMTh3Puj83J3FFTr1GwqKIuR8upDDI86GL+XLUTD+RATg8iV
 mFiQ0Xmq1Dj3Wh6JgFwKLvbIflQ0BMq4k+TiVnPhJdDmj6hDDgaMVf8vM6khQRbhzK
 11T2F+2FWt1ai0npvrlZ7pSnPsc5uq5VGMsD5O44=
Content-Type: multipart/alternative;
 boundary="===============0492176150504212196=="
MIME-Version: 1.0
Received: from [82.177.167.2] by pmq8v.m5r2.onet via HTTP id ;
 Thu, 24 Feb 2022 14:27:20 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Ruben Somsen <rsomsen@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPv7TjaY51PpA++xv5g+d6RwMOz+P4+rxSOeziGvdt_g6__05Q@mail.gmail.com>
Date: Thu, 24 Feb 2022 14:27:16 +0100
Message-Id: <132554114-6b0ae655e1150c240f98f8f865924478@pmq8v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;2
X-Mailman-Approved-At: Thu, 24 Feb 2022 14:06:43 +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: Thu, 24 Feb 2022 13:27:29 -0000

This is a multi-part message in MIME format.
--===============0492176150504212196==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> Also, tweaking an ECC point (this includes tapscript) in non-deterministi=
c ways also makes it harder to recover from backup, because you can't recov=
er the key without knowing the full commitment.
I don't think so. You can spend coins from taproot by key or by script. If =
you spend by key, making backup is simple, we have WIF for that. If you spe=
nd by script, you only need a part of the tree. So, you can "recover the ke=
y without knowing the full commitment", because you can spend coins "withou=
t knowing the full commitment". On-chain, you never reveal your "OP_RETURN =
<data>" or "OP_RETURN <hash>" or "<tapbranch> <tapbranch> <tapbranch> OP_RE=
TURN <chunk_of_data>". Those additional branches are stored only by those w=
ho wants their data to be connected with some key, knowing the full script =
is not needed, because it is not needed for on-chain validation.
> Furthermore, the scheme is not actually equivalent to op_return, because =
it requires the user to communicate out-of-band to reveal the commitment, w=
hereas with op_return the data is immediately visible (while not popular, B=
IP47 and various colored coin protocols rely on this).
Yes, but storing that additional data on-chain is not needed. It is expensi=
ve. By paying one satoshi per byte, you would pay 0.01 BTC for pushing 1 MB=
 of data. That means 1 BTC for 100 MB of data, so 15 BTC for that 1.5 GB fi=
le. And in practice it is the absolute minimum, because you have to wrap yo=
ur data somehow, you cannot just push 1.5 GB file. By placing that in TapSc=
ript, you can use your taproot public key as usual and attach any data into=
 your key for "free", because it takes zero additional bytes on-chain.
On 2022-02-24 11:08:39 user Ruben Somsen <rsomsen@gmail.com> wrote:
Note this has=C2=A0always been possible, and is not specifically related to=
 tapscript. As long as you're committing to an ECC point, you can tweak it =
to commit data inside it (i.e. pay-to-contract). This includes P2PK and P2P=
KH.
=C2=A0
Committing to 1.5GB of data has equally been possible with OP_RETURN <hash>=
, or even an entire merkle tree of hashes, as is the case with Todd's opent=
imestamps.
=C2=A0
Also, tweaking an ECC point (this includes tapscript)=C2=A0in non-determini=
stic ways also makes it harder to recover from backup, because you can't re=
cover the key without knowing the full commitment.
=C2=A0
Furthermore, the scheme is not actually equivalent to op_return, because it=
=C2=A0requires the user to communicate out-of-band to reveal the commitment=
, whereas with op_return the data is immediately visible (while not popular=
, BIP47 and various colored coin protocols rely on this).
=C2=A0
Cheers,
Ruben
=C2=A0
On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
Since Taproot was activated, we no longer need separate OP_RETURN outputs t=
o be pushed on-chain. If we want to attach any data to a transaction, we ca=
n 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 conn=
ected with some taproot address, that was pushed on-chain. Also, we can sto=
re more than 80 bytes for "free", because no such taproot branch will be ev=
er 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 a=
ddress.
=C2=A0
Currently in Bitcoin Core we have "data" field in "createrawtransaction". S=
hould the implementation be changed to place that data in a TapScript inste=
ad of creating separate OP_RETURN output? What do you think?
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============0492176150504212196==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>&gt; Also, tweaking an ECC point (this includes tapscript) in non-dete=
rministic ways also makes it harder to recover from backup, because you can=
't recover the key without knowing the full commitment.<br /><br />I don't =
think so. You can spend coins from taproot by key or by script. If you spen=
d by key, making backup is simple, we have WIF for that. If you spend by sc=
ript, you only need a part of the tree. So, you can "recover the key withou=
t knowing the full commitment", because you can spend coins "without knowin=
g the full commitment". On-chain, you never reveal your "OP_RETURN &lt;data=
&gt;" or "OP_RETURN &lt;hash&gt;" or "&lt;tapbranch&gt; &lt;tapbranch&gt; &=
lt;tapbranch&gt; OP_RETURN &lt;chunk_of_data&gt;". Those additional branche=
s are stored only by those who wants their data to be connected with some k=
ey, knowing the full script is not needed, because it is not needed for on-=
chain validation.<br /><br />&gt; Furthermore, the scheme is not actually e=
quivalent to op_return, because it requires the user to communicate out-of-=
band to reveal the commitment, whereas with op_return the data is immediate=
ly visible (while not popular, BIP47 and various colored coin protocols rel=
y on this).<br /><br />Yes, but storing that additional data on-chain is no=
t needed. It is expensive. By paying one satoshi per byte, you would pay 0.=
01 BTC for pushing 1 MB of data. That means 1 BTC for 100 MB of data, so 15=
 BTC for that 1.5 GB file. And in practice it is the absolute minimum, beca=
use you have to wrap your data somehow, you cannot just push 1.5 GB file. B=
y placing that in TapScript, you can use your taproot public key as usual a=
nd attach any data into your key for "free", because it takes zero addition=
al bytes on-chain.<br /><br /></div>
<div>On 2022-02-24 11:08:39 user Ruben Somsen &lt;rsomsen@gmail.com&gt; wro=
te:</div>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"ltr">Note this has&nbsp;always been possible, and is not specif=
ically related to tapscript. As long as you're committing to an ECC point, =
you can tweak it to commit data inside it (i.e. pay-to-contract). This incl=
udes P2PK and P2PKH.
<div>&nbsp;</div>
<div>Committing to 1.5GB of data has equally been possible with OP_RETURN &=
lt;hash&gt;, or even an entire merkle tree of hashes, as is the case with T=
odd's opentimestamps.
<div>
<div>&nbsp;</div>
<div>Also, tweaking an ECC point (this includes tapscript)&nbsp;in non-dete=
rministic ways also makes it harder to recover from backup, because you can=
't recover the key without knowing the full commitment.<br />
<div>&nbsp;</div>
<div>Furthermore, the scheme is not actually equivalent to op_return, becau=
se it&nbsp;requires the user to communicate out-of-band to reveal the commi=
tment, whereas with op_return the data is immediately visible (while not po=
pular, BIP47 and various colored coin protocols rely on this).</div>
<div>&nbsp;</div>
<div>Cheers,</div>
<div>Ruben</div>
<div>&nbsp;</div>
</div>
</div>
</div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Thu, Feb 24, 2022 at 10:19 AM vjud=
eu via bitcoin-dev &lt;<a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192d=
nQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9=
JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlA=
iBFY8" target=3D"_parent">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid #cccccc; padding-left: 1ex;">
<div>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 "OP_RETURN &lt;anything&gt;" as a branch in the TapScript. In=
 this way, we can store that data off-chain and we can always prove that th=
ey 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 &lt;1.5 GB of data&gt;", create some address having that taproot =
branch, and later prove to anyone that such "1.5 GB of data" is connected w=
ith our taproot address.</div>
<div>&nbsp;</div>
<div>Currently in Bitcoin Core we have "data" field in "createrawtransactio=
n". Should the implementation be changed to place that data in a TapScript =
instead of creating separate OP_RETURN output? What do you think?</div>
_______________________________________________<br />bitcoin-dev mailing li=
st<br /><a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5=
LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblh=
VIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" target=
=3D"_parent">bitcoin-dev@lists.linuxfoundation.org</a><br /><a href=3D"http=
s://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blan=
k" rel=3D"noopener noreferrer">https://lists.linuxfoundation.org/mailman/li=
stinfo/bitcoin-dev</a></blockquote>
</div>
</blockquote>

--===============0492176150504212196==--