1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <rsomsen@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 787B6C0011
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 10:08:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 6DFCF4026B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 10:08:39 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 ULHnEiGqv9aC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 10:08:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com
[IPv6:2607:f8b0:4864:20::1129])
by smtp4.osuosl.org (Postfix) with ESMTPS id 7E445401D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 10:08:38 +0000 (UTC)
Received: by mail-yw1-x1129.google.com with SMTP id
00721157ae682-2d62593ad9bso18772917b3.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 02:08:38 -0800 (PST)
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=VPIJ9NQi9zE+4by2lE1VpfPhswuoKr1fkw3xjgJY5/o=;
b=c1LSOs1xkh8/7q1LJRmFeSs867LQ8cE8EnzyukQ+F2sUbdTiRrwmfmvTVxPm5taeU8
hoTvLyCE7f+JP0YIpBYl6fUQq2Z1HY71EtiVuE4YQa00QhTYpwo7mtwKZRYez/QR4cmB
7hTeJFsULheN2XOOnNZ+p4xWlhstWjnhGY7rZePukBdx/2Sa7XxH5HR7jjVSV1DoD27x
hb/hfHmGEDXgy5Ht+/P8Dd6EhvFI+S9V5xP3OBlrJYjZCLIpY/C0WBbT6nQmb1zY+iTO
zew2yEFG5iAG5FmDHFHQiDY0mPeoqmv0tj73j1mVTOt77Am+UcSl5tSFOekFfOiQYtGN
FBqw==
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=VPIJ9NQi9zE+4by2lE1VpfPhswuoKr1fkw3xjgJY5/o=;
b=tSxhO5X81+VN6gbTYabpYf77YZsZeoGb86Y/Mt+aBirawiw+s/g1xIB+zKEwVdI9OZ
FvNDKh3nl03eUKg83ouo6YIPo3xIUeihkPJUfYMMpbWFdRw/Npogc5gGej0EGGUn+L4z
aiDe4E30sT2OwGZUNFo6NjViShfSminJ4qzS3yZFJMe6hS5FufEdEUOMBvk0npSmiYdE
fKwPDChGXsweXWVlbeQJ/J+5RPGB8p+wHuDSkMVpX76tlFTCJtIOVJWzjqFhvCikwNp+
MX0VRY0RumqEmt/gWfjv8rGLK4IGsp7Ag5SvG9GUPjfFh94PvMhQ0pXRzelAnflXGamZ
zOEA==
X-Gm-Message-State: AOAM532+TSzR4+NNnvqkXqiBsbaO6Q1BlFuaUXn22Z2ENWwY+8B6dgHW
kYzr/KRVoGh9TCbtZFw+rNOIO+kdvC5UBMpWJFRP/8AzzcU=
X-Google-Smtp-Source: ABdhPJzZCU0rPDOSTByyCjsu58db1UrZaT3MUuvBcgv7HU6pAcBeUrAXqjDTn0vijj/pM4MMZz9yLNC+n3xWTG2rVwU=
X-Received: by 2002:a81:6b86:0:b0:2d6:cb39:7cb6 with SMTP id
g128-20020a816b86000000b002d6cb397cb6mr1691104ywc.512.1645697317579; Thu, 24
Feb 2022 02:08:37 -0800 (PST)
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"
X-Mailman-Approved-At: Thu, 24 Feb 2022 10:09:51 +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 10:08:39 -0000
--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'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 <hash>, or even an entire merkl=
e tree of hashes, as is the case with Todd'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'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 <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</a>> 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 "OP_RETURN <anything>" 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 "free&q=
uot;, 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>&q=
uot;, create some address having that taproot branch, and later prove to an=
yone that such "1.5 GB of data" is connected with our taproot add=
ress.</div>
<div>=C2=A0</div>
<div>Currently in Bitcoin Core we have "data" field in "crea=
terawtransaction". 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--
|
