summaryrefslogtreecommitdiff
path: root/15/21d633c8b838b61a225f7865eb410320b7bb25
blob: 4ba23fbbc55f1259491d5f05ab77700bda1c0a77 (plain)
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
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
Return-Path: <rsomsen@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 261B5C002C;
 Fri, 15 Apr 2022 13:14:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 1C289404E0;
 Fri, 15 Apr 2022 13:14:55 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id l1xPwD2P-hqI; Fri, 15 Apr 2022 13:14:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com
 [IPv6:2607:f8b0:4864:20::b32])
 by smtp2.osuosl.org (Postfix) with ESMTPS id F2569400D1;
 Fri, 15 Apr 2022 13:14:52 +0000 (UTC)
Received: by mail-yb1-xb32.google.com with SMTP id t67so14478262ybi.2;
 Fri, 15 Apr 2022 06:14:52 -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=dKfsk+zl8grxx/ggqb3hg/M2lIDJuRVplAg9F8Wl8TQ=;
 b=F8xd9oydv9m4kP0PWwKJj+Hz2+fD/MPtun4owIn/F0Rn6BYjFOIrewEtkivlwu1N/x
 ieVG7+TkmXJikg0ctRQi2Vuv6ZJ09aCKVbn9ynQc/IehmK8dd0ybtL0RnTlqlOt5OWLm
 jSZ5AvcPXXq7ryBWNRgtkOBwfdixXsuuRldyI3KNudbd3z5X8Iianhiz8qOfdJaPZUK4
 TTrpwnKlRmyhyXpRl9X9cXS3zhQwESJO/mrpIxRGhLOpeLrBqiz+Ooda7PzUJlAnEsib
 9NhFfNDGRvYvdqS+8+gWYqz4wi1zv6wwrW19TtbBQ5RvqSJDkBaHY62aPeHTb8q4HiMx
 U0YQ==
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=dKfsk+zl8grxx/ggqb3hg/M2lIDJuRVplAg9F8Wl8TQ=;
 b=uFYTrhPB/QaIw5hB+G9pkyTx9Mqo0eIz8Lv/jeLXc7vSorXCBd5lZoDQgt4yVEpJ49
 L9PavJwCCDsPX4420OiYuCBGnme2188ewNorFGN18eljLPWgGQX694waJ3WHvYweHHGD
 Hjg88PupaLsSwjFn4Bbh3P8YcUlJcS/AiYEyxRrdO2pWw3KKYFSWn2KJnpCIUrrh9Q4V
 sxUVPCO7QtVMnlCqPLZCRTLnDmm2rmWA+GzP0huOPGRJ4xoL4D3ipEMGWYkEvSXBEo0Q
 lVuTuPgx0LAYETCYil8mRuJVT9pQWwJOd4xjwqJnZrfnk9n6dyv34Ecv2G3qcDhJskLs
 22hA==
X-Gm-Message-State: AOAM5318uEXVqsyUL+/rzOrkOWWw0fX0VXrWTdsYpXSt4sBOtZ65S51n
 sUIBb4luWpeAA/rKa9UPvRYFERw3lx+Ccl1csT1ez2RwZwU=
X-Google-Smtp-Source: ABdhPJwaKSlzBsweoggezAeYL6BrK5VqALgifsTW2oqIu/EIgTThaRJfvn7fZMUaZFIsl316zryaSxeAeHus4BPMgsw=
X-Received: by 2002:a05:6902:1508:b0:644:73b9:c84f with SMTP id
 q8-20020a056902150800b0064473b9c84fmr1245959ybu.272.1650028491924; Fri, 15
 Apr 2022 06:14:51 -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>
 <CAO3Pvs9mLc=6eYw=EO98CN9Muur8Kz-WHqb0sRVPQXKnJd0i9Q@mail.gmail.com>
In-Reply-To: <CAO3Pvs9mLc=6eYw=EO98CN9Muur8Kz-WHqb0sRVPQXKnJd0i9Q@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 15 Apr 2022 15:14:40 +0200
Message-ID: <CAPv7Tjavs7aNDkfE5YvRuqr2b8hfREcYBNEyOJvbWpETD=tptA@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000021670c05dcb13254"
X-Mailman-Approved-At: Fri, 15 Apr 2022 13:15:29 +0000
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: Fri, 15 Apr 2022 13:14:55 -0000

--00000000000021670c05dcb13254
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Laolu,

> 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 agree it is sufficient, but only because using Bitcoin script without an
additional scripting language inside of Taro is already sufficient. Perhaps
you could show me a concrete example where you think replicating Bitcoin's
scripting capabilities inside Taro can be useful, so I can show you where I
think it fails.

> came up with a "issuance covenant" design sketch that may or may not be
useful

To summarize my view from my first post, I basically think there are two
broad exceptions to the "can't do scripting" rule:

1. Self-encumbrance: you have to use the token according to the rules, else
the token becomes burned/invalid. The example you're giving here can be
said to fall under this category. The usefulness of this is
extremely narrow, and merely replicating Bitcoin's script inside of Taro is
certainly not sufficient to achieve it.

2. On-chain validation: instead of keeping the satisfaction of the script
off-chain, you publish it on-chain in the Bitcoin blockchain. This works,
but breaks a fundamental design goal of Taro/RGB (remaining off-chain), and
adds significant complexity.

These two points lead me to my conclusion that off-chain validation
protocols (to rule out the exception in point 2) can't do any meaningful
(to rule out the exception in point 1) scripting.

This doesn't mean you can't still add some scripting to facilitate certain
use cases that fall under the two exceptions, but a regular scripting
language for on-chain payments such as Bitcoin's is not going to cut it (at
least not without significant changes).

Personally I'd be inclined to leave out the scripting language altogether
(as the encumbrance of Bitcoin UTXOs is sufficient in most cases), unless
you have a very specific and compelling use case in mind that justify the
complexity.

Cheers,
Ruben


On Mon, Apr 11, 2022 at 9:52 PM Olaoluwa Osuntokun <laolu32@gmail.com>
wrote:

> 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 alrea=
dy
> there, but I can add the others you've listed. I might even just expand
> that
> 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
> with
> > 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 o=
n
> the security properties one is after. In the current purposefully
> simplified
> 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 an=
d
> validate the relevant set of witnesses.
>
> I was thinking about the scripting layer a bit over the weekend, and came
> up
> with a "issuance covenant" design sketch that may or may not be useful. A=
t
> 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 covena=
nt
> 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 BT=
C
>     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 o=
f
> 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
> the
> 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 lev=
el
>     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
> one
>     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
> of
> 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
> set
> 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) t=
o
> 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 th=
e
> 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
> the
> asset ID calculation.
>
> -- Laolu
>

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

<div dir=3D"ltr">Hi Laolu,<div><br></div><div>&gt; ignoring the rules leads=
 to assets being burnt, but in most cases imo that&#39;s a sufficient enoug=
h incentive to maintain and validate the relevant set of witnesses</div><di=
v><br></div><div>I agree it is sufficient, but only because using Bitcoin s=
cript without=C2=A0an additional scripting language inside of Taro is alrea=
dy sufficient. Perhaps you could show=C2=A0me a concrete example where you =
think replicating Bitcoin&#39;s scripting capabilities inside Taro can be u=
seful, so I can show you where I think it fails.</div><div><br></div><div>&=
gt; came up with a &quot;issuance covenant&quot; design sketch that may or =
may not be useful</div><div><br></div><div>To summarize my view from my fir=
st post, I basically think=C2=A0there are two broad exceptions to the &quot=
;can&#39;t do scripting&quot; rule:</div><div><br></div><div>1. Self-encumb=
rance: you have to use the token according to the rules, else the token bec=
omes burned/invalid. The example you&#39;re giving here can be said to fall=
 under this category. The usefulness of this is extremely=C2=A0narrow, and =
merely replicating Bitcoin&#39;s script inside of Taro is certainly not suf=
ficient to achieve it.</div><div><br></div><div>2. On-chain validation: ins=
tead of keeping the satisfaction of the script off-chain, you publish it on=
-chain in the Bitcoin blockchain. This works, but breaks a fundamental desi=
gn goal of Taro/RGB (remaining off-chain), and adds significant complexity.=
</div><div><br></div><div>These two points lead=C2=A0me to my conclusion th=
at off-chain validation protocols (to rule out the exception in point 2) ca=
n&#39;t do any meaningful (to rule out the exception in point 1) scripting.=
=C2=A0</div><div><br></div><div>This doesn&#39;t mean you can&#39;t still a=
dd some scripting to facilitate certain use cases that fall under the two e=
xceptions, but a regular scripting language for on-chain payments such as B=
itcoin&#39;s is not going to cut it (at least not without significant chang=
es).</div><div><br></div><div>Personally I&#39;d be inclined to leave out t=
he scripting language altogether (as the encumbrance of Bitcoin UTXOs is su=
fficient in most cases), unless you have a very specific and compelling use=
 case in mind that justify the complexity.</div><div><br></div><div>Cheers,=
</div><div>Ruben</div><div><br></div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 11, 2022 at 9:52 PM Olaolu=
wa Osuntokun &lt;<a href=3D"mailto:laolu32@gmail.com">laolu32@gmail.com</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);padding-left:1ex"><div=
 dir=3D"ltr">Hi Ruben, <br><br>&gt; Also, the people that are responsible f=
or the current shape of RGB aren&#39;t<br>&gt; the people who originated th=
e idea, so it would not be fair to the<br>&gt; originators either (Peter To=
dd, Alekos Filini, Giacomo Zucco).<br><br>Sure I have no problems acknowled=
ging them in the current BIP draft. Both<br>the protocols build off of idea=
s re client-side-validation, but then end up<br>exploring different parts o=
f the large design space.=C2=A0 Peter Todd is already<br>there, but I can a=
dd the others you&#39;ve listed. I might even just expand that<br>section i=
nto a longer &quot;Related Work&quot; section along the way.<br><br>&gt; Wh=
at I tried to say was that it does not make sense to build scripting<br>&gt=
; support into Taro, because you can&#39;t actually do anything interesting=
 with<br>&gt; it due to this limitation. =C2=A0can do with their own Taro t=
okens, or else he<br>&gt; will burn them =E2=80=93 not very useful<br><br>I=
 agree that the usage will be somewhat context specific, and dependent on<b=
r>the security properties one is after. In the current purposefully simplif=
ied<br>version, it&#39;s correct that ignoring the rules leads to assets be=
ing burnt,<br>but in most cases imo that&#39;s a sufficient enough incentiv=
e to maintain and<br>validate the relevant set of witnesses.<br><br>I was t=
hinking about the scripting layer a bit over the weekend, and came up<br>wi=
th a &quot;issuance covenant&quot; design sketch that may or may not be use=
ful. At a<br>high level, lets say we extend the system to allow a specified=
 (so a new<br>asset type) or generalized script to be validated when an ass=
et issuance<br>transaction is being validated. If we add some new domain sp=
ecific covenant<br>op codes at the Taro level, then we&#39;d be able to val=
idate issuance events<br>like:<br><br>=C2=A0 * &quot;Issuing N units of thi=
s assets can only be done if 1.5*N units of BTC<br>=C2=A0 =C2=A0 are presen=
t 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 path=
s must be<br>=C2=A0 =C2=A0 revealed, with the only acceptable unlocking lea=
f being a time lock of 9<br>=C2=A0 =C2=A0 months&quot;.<br><br>I don&#39;t =
fully have a concrete protocol that would use something like that,<br>but t=
hat was an attempt to express certain collateralization requirements<br>for=
 issuing certain assets. Verifiers would only recognize that asset if the<b=
r>issuance covenant script passes, and (perhaps) the absolute timelock on<b=
r>those coins hasn&#39;t expired yet. This seems like a useful primitive fo=
r<br>creating assets that are somehow backed by on-chain BTC collateralizat=
ion.<br>However this is just a design sketch that needs to answer questions=
 like:<br><br>=C2=A0 * are the assets still valid after that timeout period=
, or are they<br>=C2=A0 =C2=A0 considered to be burnt? <br><br>=C2=A0 * ass=
uming that the &quot;asset key family&quot; (used to authorize issuance of<=
br>=C2=A0 =C2=A0 related assets) are jointly owned, and maintained in a can=
onical<br>=C2=A0 =C2=A0 Universe, then would it be possible for 3rd parties=
 to verify the level<br>=C2=A0 =C2=A0 of collateralization on-chain, with t=
he join parties maintaining the<br>=C2=A0 =C2=A0 pool of collateralized ass=
ets accordingly?<br><br>=C2=A0 * continuing with the above, is it feasible =
to use a DLC script within one<br>=C2=A0 =C2=A0 of these fixed tapscript le=
aves to allow more collateral to be<br>=C2=A0 =C2=A0 added/removed from the=
 pool backing those assets?<br><br>I think it&#39;s too early to conclude t=
hat the scripting layer isn&#39;t useful.<br>Over time I plan to add more c=
oncrete ideas like the above to the section<br>tracking the types of applic=
ations that can be built on Taro.<br><br>&gt; So theoretically you could ge=
t Bitcoin covenants to enforce certain<br>&gt; spending conditions on Taro =
assets. Not sure how practical that ends up<br>&gt; being, but intriguing t=
o consider.<br><br>Exactly! Exactly how practical it ends up being would de=
pend on the types of<br>covenants deployed in the future. With something li=
ke a TLUV and OP_CAT (as<br>they&#39;re sufficiently generalized vs adding =
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 after=
 spending. One would use OP_CAT to<br>handle re-creating the taro asset roo=
t, and TLUV (or something similar) to<br>handle the Bitcoin tapscript part =
(swap out leaf index 0 where the taro<br>commitment is, etc).<br><br>&gt; T=
he above also reminds me of another potential issue which you need to be<br=
>&gt; aware of, if you&#39;re not already. Similar to my comment about how =
the<br>&gt; location of the Taro tree inside the taproot tree needs to be<b=
r>&gt; deterministic for the verifier, the output in which you place the Ta=
ro<br>&gt; tree also needs to be<br><br>Yep, the location needs to be fully=
 specified which includes factoring the<br>output index as well. A simple w=
ay to restrict this would just to say it&#39;s<br>always the first output. =
Otherwise, you could lift the output index into the<br>asset ID calculation=
.<br><br>-- Laolu<br></div>
</blockquote></div>

--00000000000021670c05dcb13254--