MIME-Version: 1.0
References: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet>
In-Reply-To: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Thu, 24 Feb 2022 11:08:22 +0100
Message-ID: <CAPv7TjaY51PpA++xv5g+d6RwMOz+P4+rxSOeziGvdt_g6__05Q@mail.gmail.com>
To: vjudeu <vjudeu@gazeta.pl>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000005acec05d8c0c476"
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
Precedence: list

--00000000000005acec05d8c0c476
Content-Type: text/plain; charset="UTF-8"

Note this has always 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
P2PKH.

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

Also, tweaking an ECC point (this includes tapscript) in non-deterministic
ways also makes it harder to recover from backup, because you can't recover
the key without knowing the full commitment.

Furthermore, the scheme is not actually equivalent to op_return, because
it requires 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).

Cheers,
Ruben


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
> 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.
>
> Currently in Bitcoin Core we have "data" field in "createrawtransaction".
> Should the implementation be changed to place that data in a TapScript
> instead 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
>

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

<div dir=3D"ltr">Note this has=C2=A0always been possible, and is not specif=
ically related to tapscript. As long as you&#39;re committing to an ECC poi=
nt, you can tweak it to commit data inside it (i.e. pay-to-contract). This =
includes P2PK and P2PKH.<div><br></div><div>Committing to 1.5GB of data has=
 equally been possible with OP_RETURN &lt;hash&gt;, or even an entire merkl=
e tree of hashes, as is the case with Todd&#39;s opentimestamps.<div><div><=
br></div><div>Also, tweaking an ECC point (this includes tapscript)=C2=A0in=
 non-deterministic ways also makes it harder to recover from backup, becaus=
e you can&#39;t recover the key without knowing the full commitment.<br><di=
v><br></div><div>Furthermore, the scheme is not actually equivalent to op_r=
eturn, because it=C2=A0requires the user to communicate out-of-band to reve=
al the commitment, whereas with op_return the data is immediately visible (=
while not popular, BIP47 and various colored coin protocols rely on this).<=
/div><div><br></div><div>Cheers,</div><div>Ruben</div><div><br></div></div>=
</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div>Since Taproot was activated, we no longer need separat=
e OP_RETURN outputs 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 b=
ranch in the TapScript. In this way, we can store that data off-chain and w=
e 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 &quot;free&q=
uot;, because no such taproot branch will be ever pushed on-chain and used =
as an input. That means we can use &quot;OP_RETURN &lt;1.5 GB of data&gt;&q=
uot;, create some address having that taproot branch, and later prove to an=
yone that such &quot;1.5 GB of data&quot; is connected with our taproot add=
ress.</div>
<div>=C2=A0</div>
<div>Currently in Bitcoin Core we have &quot;data&quot; field in &quot;crea=
terawtransaction&quot;. 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 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>

--00000000000005acec05d8c0c476--