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
|
Return-Path: <zachgrw@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8124BC0011
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:41:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7086983E7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:41:09 +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: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xgK-1jjqcsjz
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:41:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com
[IPv6:2607:f8b0:4864:20::d32])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8AAF1827FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:41:08 +0000 (UTC)
Received: by mail-io1-xd32.google.com with SMTP id s1so4354856iob.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 13:41:08 -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=geXJRzKMAdtwWQuu8FKC/fllgU0UOE6s+TsX+J2iGao=;
b=WCM55zaoq+9pk/FRPh4BZ0hP4nl6CILIKWQlo0F9QIcfYI5EDIhzL87Q2j/Vtb3Bu/
Zx/3jU5g7ev3ZE+mC5Rpdss3twnt2FkHh9aYH9Qwt83ru5hgH2GSH5pweFsXx7vR2iVO
TUK1N3pDX7ol9NrQhiwhJp4PkCahBVzmleVw9MMl8hWiLStiGHPqcBeXAyzVuzOp0mxT
L/UR5mnV8TdO8uDbF50L0zwhQsRNkqDt+QjyTtLqPYtciQCXwLJqCwRzbJ8ocWCxkIU3
Pqa76hRyl9twaq5TQI8Xd9sCLLWfGolg0m5Ude4c0FHMkUwsHAQrkx6b5ExcPlwrB2V/
f6Jg==
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=geXJRzKMAdtwWQuu8FKC/fllgU0UOE6s+TsX+J2iGao=;
b=xzZkMgNBZ05ar6ZWWhmOaAPSz7D7Fy1nAtfPl6845mpqelNLDGl9qhq4QgVVO2hVS/
Y6nUTun4wScrhVJVfevWjgsbi8kP5jkqefb+RLgVHBsLdzMI8f+hy5vat8NffPuTccQg
R2Ncs+3LuLvUWekXJGF8ieRCuqUdDvNAwA0Y5dSCCw5WTUTG20DOz5JqXayL8xvF8mhj
LcejuU5Yg1DbfoFSn309nsQTfnmaXh9jbhPmsgVWnPtVYGkoHBkNNHq9qSn7nWJ5CQoi
zYK84nUuWoWa8SbGaRUI+iH8x7oTxa1UPMcGWd261EEYXpquvP4c7qiEfmkWEwg4wvDb
umng==
X-Gm-Message-State: AOAM531mFEGjy9pgoIAONOhyCG6aFYvIC+Z48RY6afHYJKHdzbuRxlBK
y2LwbV1I82PSLRJkdZpYvYdGwDXdZR0Cso9/n8PIinED
X-Google-Smtp-Source: ABdhPJxqYR8JeswSWDprAlThM06hbz+qu/x8xpBG02fzJeM8PYQ7Ki9FiIcdoS4TDMjCv3u4Sl/APe4sN5iwPxZaOp4=
X-Received: by 2002:a02:852b:0:b0:315:3aaa:dbad with SMTP id
g40-20020a02852b000000b003153aaadbadmr3152722jai.309.1645738867638; Thu, 24
Feb 2022 13:41:07 -0800 (PST)
MIME-Version: 1.0
References: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet>
In-Reply-To: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Thu, 24 Feb 2022 22:40:57 +0100
Message-ID: <CAJ4-pEBnprd-SdXMZeDsJ37=SiGbQEnaFfpvBzryR21Wbqc1Ew@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="00000000000099470205d8ca7059"
X-Mailman-Approved-At: Thu, 24 Feb 2022 21:44:39 +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 21:41:09 -0000
--00000000000099470205d8ca7059
Content-Type: text/plain; charset="UTF-8"
Reducing the footprint of storing data on-chain might better be achieved by
*supporting* it.
Currently storing data is wasteful because it is embedded inside an
OP_RETURN within a transaction structure. As an alternative, by supporting
storing of raw data without creating a transaction, waste can be reduced.
Storing data in this way must only be marginally cheaper per on-chain byte
than the current method using OP_RETURN by applying the appropriate
weight-per-byte for on-chain data.
The intended result is a smaller footprint for on-chain data without making
it cheaper (except marginally in order to disincentivize the use of
OP_RETURN).
Zac
On Thu, 24 Feb 2022 at 10:19, 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
>
--00000000000099470205d8ca7059
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Reducing the footprint of storing data on-chain might bet=
ter be achieved by *supporting* it.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Currently storing data is wasteful because it is embedded insid=
e an OP_RETURN within a transaction structure. As an alternative, by suppor=
ting storing of raw data without creating a transaction, waste can be reduc=
ed.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Storing data in this=
way must only be marginally cheaper per on-chain byte than the current met=
hod =C2=A0using OP_RETURN by applying the appropriate weight-per-byte for o=
n-chain data.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The intend=
ed result is a smaller footprint for on-chain data without making it cheape=
r (except marginally in order to disincentivize the use of OP_RETURN).=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Zac</div><div dir=3D=
"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">On Thu, 24 F=
eb 2022 at 10:19, vjudeu via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wr=
ote:</div><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div>Since Tapro=
ot 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 &q=
uot;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 ca=
n store more than 80 bytes for "free", because no such taproot br=
anch will be ever pushed on-chain and used as an input. That means we can u=
se "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 d=
ata" is connected with our taproot address.</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></div>
--00000000000099470205d8ca7059--
|
