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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
|
Return-Path: <laolu32@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id A91E8C002C;
Mon, 11 Apr 2022 19:52:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 8E271414C3;
Mon, 11 Apr 2022 19:52:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 0tVfRIolO4Tj; Mon, 11 Apr 2022 19:52:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com
[IPv6:2a00:1450:4864:20::32c])
by smtp4.osuosl.org (Postfix) with ESMTPS id E4246414C2;
Mon, 11 Apr 2022 19:52:08 +0000 (UTC)
Received: by mail-wm1-x32c.google.com with SMTP id
h126-20020a1c2184000000b0038eb17fb7d6so219519wmh.2;
Mon, 11 Apr 2022 12:52:08 -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
:cc; bh=ALgM/RGosxq4WRYD7VxJMGHDTTkuGyHr+ABPgGh7wdo=;
b=Pt38uHdfKYjTwzB6I+umFCWrbhxN/N7ZMYNdEMTLRVT+oaxmQPqgZezK167YYl+pP7
b+lyi7ctOySWyOaYb7L19R50NuPvwKejzIZlWc5tHTJzlROnhhMkOcpkQalTFy9bMuq0
EYNdnxqsZ2yTcLTTRIN+7RXzMBn8nKkx4G3Vo/O/pZ/xC+NFaTqMTHsqY06PcTGclpxB
oj3hzu0aIbFuB08/pgXYY2ukYtbm0WFHsZElnYZycBAduec3z6M25Z25/eVKStHtbTEI
3qyRq4jChUTjzpt5D67gsjG3e/u8l4fcykOv3H6aCigLPqsgkQ7VsDUp0ynzKCmj5+2W
ripg==
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:cc;
bh=ALgM/RGosxq4WRYD7VxJMGHDTTkuGyHr+ABPgGh7wdo=;
b=dqrL5v06fKtaNIsXy+sMQ6iMCkZKd+d3qwL4ocvTVxdjtvyFIaykm8lsQQSlG7AdP9
dFnfjxC4+LnpSoE1yP0mGRNravaemcz0ZMqVWKolZbyaRfAvXQfCYG1Aw0EyNQDJ5Vvu
sTSnQUwh/DnOQeBmyWlA8YMxqIyBuz9TdvuxnA1h4Fo/HUK8StmGLDkYzYOq08BL9azk
M7b0skW19fIQfOULh0pVKNbO3t94AK8+h+7wUbGQIgOmHBz/Nuxd1RId/8yuyh02a8kx
vpdSudbIm8Z0Veq4qvEvNFBtaf7I41fGGSpZc88LJF6tlw9TB1oovK2vlC3/OliijoaE
si8Q==
X-Gm-Message-State: AOAM533AnQlMap2Wti6haSC9Rdm2b+UeTMiXd6z3lXF6QdZBA0HE+D08
1iz49SQ+TbugASAK9O0Ou3om3su0K/76nvNzJWFJi4BBZ9Q=
X-Google-Smtp-Source: ABdhPJwbCxtR/oKXmmuHXoA/hxPGAz9RljMdjUwCutuFQnNYh8xhYXD+XkgQw3OADqb/A7oXLXQikqQvKmB3DdQTl0o=
X-Received: by 2002:a1c:6a02:0:b0:38b:3661:47f1 with SMTP id
f2-20020a1c6a02000000b0038b366147f1mr699886wmc.5.1649706726807; Mon, 11 Apr
2022 12:52:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAO3Pvs_pkYAYsrAEtv3KuJevXQHBLZQ-ihjP4Ur_A1NjJRA+Lw@mail.gmail.com>
<CAPv7TjYTjvSV7UFgOwif6tFj3jVxDfJdW-p_cyPoAGGWKQbwRQ@mail.gmail.com>
<CAO3Pvs_-igT37fcD29=ATSRX7dW5mGKrLGrXp=iJjaN_t3NGww@mail.gmail.com>
<CAPv7TjZjZU2bYvUrt-BEx80xKF=BHBbrYWigHB+=yY+YfZX9Yg@mail.gmail.com>
In-Reply-To: <CAPv7TjZjZU2bYvUrt-BEx80xKF=BHBbrYWigHB+=yY+YfZX9Yg@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Mon, 11 Apr 2022 15:51:55 -0400
Message-ID: <CAO3Pvs9mLc=6eYw=EO98CN9Muur8Kz-WHqb0sRVPQXKnJd0i9Q@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006f5e3b05dc664735"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
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, 11 Apr 2022 19:52:10 -0000
--0000000000006f5e3b05dc664735
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Ruben,
> Also, the people that are responsible for the current shape of RGB aren't
> the people who originated the idea, so it would not be fair to the
> originators either (Peter Todd, Alekos Filini, Giacomo Zucco).
Sure I have no problems acknowledging them in the current BIP draft. Both
the protocols build off of ideas re client-side-validation, but then end up
exploring different parts of the large design space. Peter Todd is already
there, but I can add the others you've listed. I might even just expand tha=
t
section into a longer "Related Work" section along the way.
> What I tried to say was that it does not make sense to build scripting
> support into Taro, because you can't actually do anything interesting wit=
h
> it due to this limitation. can do with their own Taro tokens, or else he
> will burn them =E2=80=93 not very useful
I agree that the usage will be somewhat context specific, and dependent on
the security properties one is after. In the current purposefully simplifie=
d
version, it's correct that ignoring the rules leads to assets being burnt,
but in most cases imo that's a sufficient enough incentive to maintain and
validate the relevant set of witnesses.
I was thinking about the scripting layer a bit over the weekend, and came u=
p
with a "issuance covenant" design sketch that may or may not be useful. At =
a
high level, lets say we extend the system to allow a specified (so a new
asset type) or generalized script to be validated when an asset issuance
transaction is being validated. If we add some new domain specific covenant
op codes at the Taro level, then we'd be able to validate issuance events
like:
* "Issuing N units of this assets can only be done if 1.5*N units of BTC
are present in the nth output of the minting transaction. In addition,
the output created must commit to a NUMs point for the internal key,
meaning that only a script path is possible. The script paths must be
revealed, with the only acceptable unlocking leaf being a time lock of =
9
months".
I don't fully have a concrete protocol that would use something like that,
but that was an attempt to express certain collateralization requirements
for issuing certain assets. Verifiers would only recognize that asset if th=
e
issuance covenant script passes, and (perhaps) the absolute timelock on
those coins hasn't expired yet. This seems like a useful primitive for
creating assets that are somehow backed by on-chain BTC collateralization.
However this is just a design sketch that needs to answer questions like:
* are the assets still valid after that timeout period, or are they
considered to be burnt?
* assuming that the "asset key family" (used to authorize issuance of
related assets) are jointly owned, and maintained in a canonical
Universe, then would it be possible for 3rd parties to verify the level
of collateralization on-chain, with the join parties maintaining the
pool of collateralized assets accordingly?
* continuing with the above, is it feasible to use a DLC script within on=
e
of these fixed tapscript leaves to allow more collateral to be
added/removed from the pool backing those assets?
I think it's too early to conclude that the scripting layer isn't useful.
Over time I plan to add more concrete ideas like the above to the section
tracking the types of applications that can be built on Taro.
> So theoretically you could get Bitcoin covenants to enforce certain
> spending conditions on Taro assets. Not sure how practical that ends up
> being, but intriguing to consider.
Exactly! Exactly how practical it ends up being would depend on the types o=
f
covenants deployed in the future. With something like a TLUV and OP_CAT (as
they're sufficiently generalized vs adding op codes to very the proofs) a
Script would be able to re-create the set of commitments to restrict the se=
t
of outputs that can be created after spending. One would use OP_CAT to
handle re-creating the taro asset root, and TLUV (or something similar) to
handle the Bitcoin tapscript part (swap out leaf index 0 where the taro
commitment is, etc).
> The above also reminds me of another potential issue which you need to be
> aware of, if you're not already. Similar to my comment about how the
> location of the Taro tree inside the taproot tree needs to be
> deterministic for the verifier, the output in which you place the Taro
> tree also needs to be
Yep, the location needs to be fully specified which includes factoring the
output index as well. A simple way to restrict this would just to say it's
always the first output. Otherwise, you could lift the output index into th=
e
asset ID calculation.
-- Laolu
--0000000000006f5e3b05dc664735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Ruben, <br><br>> Also, the people that are responsib=
le for the current shape of RGB aren't<br>> the people who originate=
d the idea, so it would not be fair to the<br>> originators either (Pete=
r Todd, Alekos Filini, Giacomo Zucco).<br><br>Sure I have no problems ackno=
wledging them in the current BIP draft. Both<br>the protocols build off of =
ideas re client-side-validation, but then end up<br>exploring different par=
ts of the large design space.=C2=A0 Peter Todd is already<br>there, but I c=
an add the others you've listed. I might even just expand that<br>secti=
on into a longer "Related Work" section along the way.<br><br>>=
; What I tried to say was that it does not make sense to build scripting<br=
>> support into Taro, because you can't actually do anything interes=
ting with<br>> it due to this limitation. =C2=A0can do with their own Ta=
ro tokens, or else he<br>> will burn them =E2=80=93 not very useful<br><=
br>I agree that the usage will be somewhat context specific, and dependent =
on<br>the security properties one is after. In the current purposefully sim=
plified<br>version, it's correct that ignoring the rules leads to asset=
s being burnt,<br>but in most cases imo that's a sufficient enough ince=
ntive to maintain and<br>validate the relevant set of witnesses.<br><br>I w=
as thinking about the scripting layer a bit over the weekend, and came up<b=
r>with a "issuance covenant" design sketch that may or may not be=
useful. At a<br>high level, lets say we extend the system to allow a speci=
fied (so a new<br>asset type) or generalized script to be validated when an=
asset issuance<br>transaction is being validated. If we add some new domai=
n specific covenant<br>op codes at the Taro level, then we'd be able to=
validate issuance events<br>like:<br><br>=C2=A0 * "Issuing N units of=
this assets can only be done if 1.5*N units of BTC<br>=C2=A0 =C2=A0 are pr=
esent in the nth output of the minting transaction. In addition,<br>=C2=A0 =
=C2=A0 the output created must commit to a NUMs point for the internal key,=
<br>=C2=A0 =C2=A0 meaning that only a script path is possible. The script p=
aths must be<br>=C2=A0 =C2=A0 revealed, with the only acceptable unlocking =
leaf being a time lock of 9<br>=C2=A0 =C2=A0 months".<br><br>I don'=
;t fully have a concrete protocol that would use something like that,<br>bu=
t that was an attempt to express certain collateralization requirements<br>=
for issuing certain assets. Verifiers would only recognize that asset if th=
e<br>issuance covenant script passes, and (perhaps) the absolute timelock o=
n<br>those coins hasn't expired yet. This seems like a useful primitive=
for<br>creating assets that are somehow backed by on-chain BTC collaterali=
zation.<br>However this is just a design sketch that needs to answer questi=
ons like:<br><br>=C2=A0 * are the assets still valid after that timeout per=
iod, or are they<br>=C2=A0 =C2=A0 considered to be burnt? <br><br>=C2=A0 * =
assuming that the "asset key family" (used to authorize issuance =
of<br>=C2=A0 =C2=A0 related assets) are jointly owned, and maintained in a =
canonical<br>=C2=A0 =C2=A0 Universe, then would it be possible for 3rd part=
ies to verify the level<br>=C2=A0 =C2=A0 of collateralization on-chain, wit=
h the join parties maintaining the<br>=C2=A0 =C2=A0 pool of collateralized =
assets accordingly?<br><br>=C2=A0 * continuing with the above, is it feasib=
le to use a DLC script within one<br>=C2=A0 =C2=A0 of these fixed tapscript=
leaves to allow more collateral to be<br>=C2=A0 =C2=A0 added/removed from =
the pool backing those assets?<br><br>I think it's too early to conclud=
e that the scripting layer isn't useful.<br>Over time I plan to add mor=
e concrete ideas like the above to the section<br>tracking the types of app=
lications that can be built on Taro.<br><br>> So theoretically you could=
get Bitcoin covenants to enforce certain<br>> spending conditions on Ta=
ro assets. Not sure how practical that ends up<br>> being, but intriguin=
g to consider.<br><br>Exactly! Exactly how practical it ends up being would=
depend on the types of<br>covenants deployed in the future. With something=
like a TLUV and OP_CAT (as<br>they're sufficiently generalized vs addi=
ng op codes to very the proofs) a<br>Script would be able to re-create the =
set of commitments to restrict the set<br>of outputs that can be created af=
ter spending. One would use OP_CAT to<br>handle re-creating the taro asset =
root, and TLUV (or something similar) to<br>handle the Bitcoin tapscript pa=
rt (swap out leaf index 0 where the taro<br>commitment is, etc).<br><br>>=
; The above also reminds me of another potential issue which you need to be=
<br>> aware of, if you're not already. Similar to my comment about h=
ow the<br>> location of the Taro tree inside the taproot tree needs to b=
e<br>> deterministic for the verifier, the output in which you place the=
Taro<br>> tree also needs to be<br><br>Yep, the location needs to be fu=
lly specified which includes factoring the<br>output index as well. A simpl=
e way to restrict this would just to say it's<br>always the first outpu=
t. Otherwise, you could lift the output index into the<br>asset ID calculat=
ion.<br><br>-- Laolu<br></div>
--0000000000006f5e3b05dc664735--
|
