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
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
|
Return-Path: <laolu32@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 66EBBC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 02:40:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 3907883F2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 02:40:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3907883F2B
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=F8l2HEMu
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
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 zIbC5qR7MiBK
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 02:40:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0DC4E83F21
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
[IPv6:2a00:1450:4864:20::42f])
by smtp1.osuosl.org (Postfix) with ESMTPS id 0DC4E83F21
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 02:40:27 +0000 (UTC)
Received: by mail-wr1-x42f.google.com with SMTP id u10so26822005wrq.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Oct 2022 19:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=41kbP99uaxh7/QRkIoPWTu9GGl38ASzw+MCf8g79Rts=;
b=F8l2HEMuKWia2uJ+dBIKB3BvEXvQtIO4wG35FzMCqht2s1s1X/cAv9NG9eZ4IsRX4R
CNelXokGqTj20xp6uDVAHRE8E5pK9dieP2MowHepiF4ZD+bBLm8DTNpiOC0tPlr/t1U1
q0s0irQ8pKzGxaiOE4W8X+V/01NU9yt8z970wXrV6Rh7wgM3ru0SI+sG4pkOBU7X59FF
ePCmQb2AL+LqnJAk+DBDMqG+mCDr8/KaBL/L1JNxD99rGmomn57XhASU0nivpumjxkIn
FkJPK2qeJIYd+FMYdZcaOXlzfXtFCF++Dk/BNkX7CnTnkYLRfT7AE5NO0CwvPZM039zc
iQUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=41kbP99uaxh7/QRkIoPWTu9GGl38ASzw+MCf8g79Rts=;
b=zl2RfJz5YayWxwnQpazbN9s2AarG01TJc2HRrxTewaZtv1e0gbNmrv+uxL5HCI9DjU
yQ4QwSw28NZFXyPntK4gjvqQV1hGkGzaNRRusLAIYaXhPpor92bnFh0bYKcAsB3zKyuW
vRWGPVXrM4nbh6YSuTJgxuhxtxtKBdGWc8tfHr6Hd5dEmjlaOVXBt3nPaWq3PpzF5wiu
Cs1MUMxLcEVvbat0yXTWeYQzbKquoJ86NhyIDXEUjTJJulSGJrfzMrXs8rdA18/vbHWZ
stbElsDNxKyR3VY0M6C4XggCD4YdhyFHIEFKp9cg5E4ou+sKxTHY1GBGtz1mJTJeKwZv
QC/Q==
X-Gm-Message-State: ACrzQf3VK3JZAQf5OBsC7AO6cCcwqVfkrd0KVbF8wJ+9N/Ww6X6BPx+8
W8GNudeqyM7aTQBoUZTL/vJLOGvDg/jPd/D2VlYup3SSeSKDYR9L
X-Google-Smtp-Source: AMsMyM4DZclFpAkU0Eqw43F4EWZrWS5h83xTDm8sgQ0y/M518ANXAEuZ42igaiURXIonjSol8L9OglggntmK3peyxiE=
X-Received: by 2002:a5d:6c6f:0:b0:22e:46ad:c3d6 with SMTP id
r15-20020a5d6c6f000000b0022e46adc3d6mr3409712wrz.677.1666147225760; Tue, 18
Oct 2022 19:40:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAO3Pvs_pkYAYsrAEtv3KuJevXQHBLZQ-ihjP4Ur_A1NjJRA+Lw@mail.gmail.com>
<CAO6oAq2nC9_0GdoOQbmX3Qt4OsSYzMVBy-vyGczwn1GhLHN2Kw@mail.gmail.com>
In-Reply-To: <CAO6oAq2nC9_0GdoOQbmX3Qt4OsSYzMVBy-vyGczwn1GhLHN2Kw@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 18 Oct 2022 19:40:13 -0700
Message-ID: <CAO3Pvs-2DXYT7PW-KfHcyrzWSya55w57MfKqtxq5HuAFcj3etw@mail.gmail.com>
To: Hiroki Gondo <hiroki.gondo@nayuta.co>
Content-Type: multipart/alternative; boundary="00000000000088f96f05eb5a21eb"
Cc: Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-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: Wed, 19 Oct 2022 02:40:31 -0000
--00000000000088f96f05eb5a21eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Hiroki,
(inserting the bitcoin-dev mailing list as this question is mainly
concerning on-chain interaction)
Thanks for taking the time to really dig into things!
> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction graphs without gaps from
> the genesis transaction of the asset to the current location
> It is necessary to prove and verify that =E2=80=9Cthe UTXO has not change=
d=E2=80=9D at
> that point.
Correct!
> As far as I can see, the specs don't mention it.
You're correct that today the main BIP draft focuses mainly on transfers [1=
]
to specify how exactly an asset moves from one output to another. The
requirement that a "no-op" state transition also be created/verified is an
implicit assumption in the current spec that we aim to remedy. The current
alpha code [2] is a bit ahead of the spec, but we aim to start to catch up
the spec, and also begin to add test vectors now that we have a working
implementation.
> The proofs for directly proving that a UTXO has not changed are its
> inclusion proof in the input asset tree and its inclusion and
> non-inclusion proofs in each of the output asset trees
Correct, the set of inclusion and non-inclusion proofs necessary for a vali=
d
state transition are currently documented in `bip-taro-proof-file.md` [3].
We've also made a few updates to the proof file format to properly include =
a
field for the inclusion proof of a split asset's _root_ asset. This allows
verifiers to properly verify the authenticity of the split (root is in the
transaction, uniquely, which commits to the split, which has a proof
anchored in that spit root).
> Instead, it's better to set a constraint that no part of the asset tree
> except the explicitly changed UTXOs should change, and verify that.
Interesting, so rather than present/maintain a distinct state transition fo=
r
each asset unaffected, you propose that instead we present a _single_ proof
for all non-modified assets that shows that a sub-tree/branch is unchanged?
That's a very cool idea.
Generally we have a lot of low hanging fruits re optimizing the proof file
format itself. As an example, all assets in a tree will share the same
Bitcoin-level proof prefix (merkle proof and block header of the anchor
transaction), but the spec/implementation will currently duplicate those
values several times over for each asset. If we go down another level, then
the main inclusion proof for an asset ID tree is also duplicated for each
asset sharing that asset ID.
Restating things a bit: right now proofs are oriented from the PoV of an
asset leaf in question. Instead, if we zoom out a bit and orient them at th=
e
_taproot output_ level, then we can remove a lot of redundant data in the
current proof format, then sort of "prune" the output level proof to
generate a proof for a single leaf.
-- Laolu
[1]:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki#asset-tra=
nsfers
[2]: https://github.com/lightninglabs/taro
[3]:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawik=
i#specification
On Fri, Oct 7, 2022 at 2:33 AM Hiroki Gondo <hiroki.gondo@nayuta.co> wrote:
> Hi Laolu,
>
> I've read Taro's specs, but I'm afraid there's not enough verification of
> the provenance of the asset UTXOs.
>
> When trying to verify the provenance of a given UTXO, it is necessary to
> verify the state transitions of all transaction graphs without gaps from
> the genesis transaction of the asset to the current location. At some poi=
nt
> in the transaction, the target UTXO itself may not change (only changes t=
o
> other assets or other UTXOs in the asset tree). It is necessary to prove
> and verify that =E2=80=9Cthe UTXO has not changed=E2=80=9D at that point.=
As far as I can
> see, the specs don't mention it.
>
> Without this validation, asset inflation (double spending) is possible. I=
n
> a transaction, there is a UTXO in the input asset tree. If this UTXO does
> not change in this transaction, it will remain in the output asset tree.
> However, if a full copy of this UTXO is illicitly created in the asset tr=
ee
> of another output, the asset will be inflated (even duplicating the lowes=
t
> MS-SMT entirely). Both UTXOs will arbitrarily claim to be the same as the
> input UTXO.
>
> The proofs for directly proving that a UTXO has not changed are its
> inclusion proof in the input asset tree and its inclusion and non-inclusi=
on
> proofs in each of the output asset trees. However, generating these proof=
s
> for every unchanging UTXO present in the input asset tree when a
> transaction occurs may not be very practical. Instead, it's better to set=
a
> constraint that no part of the asset tree except the explicitly changed
> UTXOs should change, and verify that.
>
> Please let me know if I'm wrong or have overlooked any specs. Also, let m=
e
> know if there's anything about this that hasn't been mentioned in the spe=
cs
> yet.
>
> =E2=80=93
> Hiroki Gondo
>
>
> 2022=E5=B9=B44=E6=9C=886=E6=97=A5(=E6=B0=B4) 0:06 Olaoluwa Osuntokun <lao=
lu32@gmail.com>:
>
>> Hi y'all,
>>
>> I'm excited to publicly publish a new protocol I've been working on over
>> the
>> past few months: Taro. Taro is a Taproot Asset Representation Overlay
>> which
>> allows the issuance of normal and also collectible assets on the main
>> Bitcoin
>> chain. Taro uses the Taproot script tree to commit extra asset structure=
d
>> meta
>> data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tre=
e
>> or
>> MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a
>> sparse
>> merkle tree, enabling things like easily verifiable asset supply proofs
>> and
>> also efficient proofs of non existence (eg: you prove to me you're no
>> longer
>> committing to the 1-of-1 holographic beefzard card during our swap). Tar=
o
>> asset
>> transfers are then embedded in a virtual/overlay transaction graph which
>> uses a
>> chain of asset witnesses to provably track the transfer of assets across
>> taproot outputs. Taro also has a scripting system, which allows for
>> programmatic unlocking/transfer of assets. In the first version, the
>> scripting
>> system is actually a recursive instance of the Bitcoin Script Taproot VM=
,
>> meaning anything that can be expressed in the latest version of Script
>> can be
>> expressed in the Taro scripting system. Future versions of the scripting
>> system
>> can introduce new functionality on the Taro layer, like covenants or oth=
er
>> updates.
>>
>> The Taro design also supports integration with the Lightning Network
>> (BOLTs) as
>> the scripting system can be used to emulate the existing HTLC structure,
>> which
>> allows for multi-hop transfers of Taro assets. Rather than modify the
>> internal
>> network, the protocol proposes to instead only recognize "assets at the
>> edges",
>> which means that only the sender+receiver actually need to know about an=
d
>> validate the assets. This deployment route means that we don't need to
>> build up
>> an entirely new network and liquidity for each asset. Instead, all asset
>> transfers will utilize the Bitcoin backbone of the Lightning Network,
>> which
>> means that the internal routers just see Bitcoin transfers as normal, an=
d
>> don't
>> even know about assets at the edges. As a result, increased demand for
>> transfers of these assets as the edges (say like a USD stablecoin), whic=
h
>> in
>> will turn generate increased demand of LN capacity, result in more
>> transfers, and
>> also more routing revenue for the Bitcoin backbone nodes.
>>
>> The set of BIPs are a multi-part suite, with the following breakdown:
>> * The main Taro protocol:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
>> * The MS-SMT structure:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
>> * The Taro VM:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
>> * The Taro address format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
>> * The Taro Universe concept:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawi=
ki
>> * The Taro flat file proof format:
>> https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.media=
wiki
>>
>> Rather than post them all in line (as the text wouldn't fit in the
>> allowed size
>> limit), all the BIPs can be found above.
>>
>> -- Laolu
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
--00000000000088f96f05eb5a21eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Hiroki,<br><br>(inserting the bitcoin-dev mailing list =
as this question is mainly<br>concerning on-chain interaction)<br><br>Thank=
s for taking the time to really dig into things!<br><br>> When trying to=
verify the provenance of a given UTXO, it is necessary to<br>> verify t=
he state transitions of all transaction graphs without gaps from<br>> th=
e genesis transaction of the asset to the current location<br><br>> It i=
s necessary to prove and verify that =E2=80=9Cthe UTXO has not changed=E2=
=80=9D at<br>> that point.<br><br>Correct!<br><br>> As far as I can s=
ee, the specs don't mention it.<br><br>You're correct that today th=
e main BIP draft focuses mainly on transfers [1]<br>to specify how exactly =
an asset moves from one output to another. The<br>requirement that a "=
no-op" state transition also be created/verified is an<br>implicit ass=
umption in the current spec that we aim to remedy. The current<br>alpha cod=
e [2] is a bit ahead of the spec, but we aim to start to catch up<br>the sp=
ec, and also begin to add test vectors now that we have a working<br>implem=
entation.<br><br>> The proofs for directly proving that a UTXO has not c=
hanged are its<br>> inclusion proof in the input asset tree and its incl=
usion and<br>> non-inclusion proofs in each of the output asset trees<br=
><br>Correct, the set of inclusion and non-inclusion proofs necessary for a=
valid<br>state transition are currently documented in `bip-taro-proof-file=
.md` [3].<br>We've also made a few updates to the proof file format to =
properly include a<br>field for the inclusion proof of a split asset's =
_root_ asset. This allows<br>verifiers to properly verify the authenticity =
of the split (root is in the<br>transaction, uniquely, which commits to the=
split, which has a proof<br>anchored in that spit root).<br><br>> Inste=
ad, it's better to set a constraint that no part of the asset tree<br>&=
gt; except the explicitly changed UTXOs should change, and verify that.<br>=
<br>Interesting, so rather than present/maintain a distinct state transitio=
n for<br>each asset unaffected, you propose that instead we present a _sing=
le_ proof<br>for all non-modified assets that shows that a sub-tree/branch =
is unchanged?<br>That's a very cool idea. <br><br>Generally we have a l=
ot of low hanging fruits re optimizing the proof file<br>format itself. As =
an example, all assets in a tree will share the same<br>Bitcoin-level proof=
prefix (merkle proof and block header of the anchor<br>transaction), but t=
he spec/implementation will currently duplicate those<br>values several tim=
es over for each asset. If we go down another level, then<br>the main inclu=
sion proof for an asset ID tree is also duplicated for each<br>asset sharin=
g that asset ID.<br><br>Restating things a bit: right now proofs are orient=
ed from the PoV of an<br>asset leaf in question. Instead, if we zoom out a =
bit and orient them at the<br>_taproot output_ level, then we can remove a =
lot of redundant data in the<br>current proof format, then sort of "pr=
une" the output level proof to<br>generate a proof for a single leaf.<=
br><br>-- Laolu<br><br>[1]: <a href=3D"https://github.com/Roasbeef/bips/blo=
b/bip-taro/bip-taro.mediawiki#asset-transfers">https://github.com/Roasbeef/=
bips/blob/bip-taro/bip-taro.mediawiki#asset-transfers</a><br>[2]: <a href=
=3D"https://github.com/lightninglabs/taro">https://github.com/lightninglabs=
/taro</a><br>[3]: <a href=3D"https://github.com/Roasbeef/bips/blob/bip-taro=
/bip-taro-proof-file.mediawiki#specification">https://github.com/Roasbeef/b=
ips/blob/bip-taro/bip-taro-proof-file.mediawiki#specification</a><br></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri=
, Oct 7, 2022 at 2:33 AM Hiroki Gondo <<a href=3D"mailto:hiroki.gondo@na=
yuta.co">hiroki.gondo@nayuta.co</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hi Laolu=
,<br><br>I've read Taro's specs, but I'm afraid there's not=
enough verification of the provenance of the asset UTXOs.<br><br>When tryi=
ng to verify the provenance of a given UTXO, it is necessary to verify the =
state transitions of all transaction graphs without gaps from the genesis t=
ransaction of the asset to the current location. At some point in the trans=
action, the target UTXO itself may not change (only changes to other assets=
or other UTXOs in the asset tree). It is necessary to prove and verify tha=
t =E2=80=9Cthe UTXO has not changed=E2=80=9D at that point. As far as I can=
see, the specs don't mention it.<br><br>Without this validation, asset=
inflation (double spending) is possible. In a transaction, there is a UTXO=
in the input asset tree. If this UTXO does not change in this transaction,=
it will remain in the output asset tree. However, if a full copy of this U=
TXO is illicitly created in the asset tree of another output, the asset wil=
l be inflated (even duplicating the lowest MS-SMT entirely). Both UTXOs wil=
l arbitrarily claim to be the same as the input UTXO.<br><br>The proofs for=
directly proving that a UTXO has not changed are its inclusion proof in th=
e input asset tree and its inclusion and non-inclusion proofs in each of th=
e output asset trees. However, generating these proofs for every unchanging=
UTXO present in the input asset tree when a transaction occurs may not be =
very practical. Instead, it's better to set a constraint that no part o=
f the asset tree except the explicitly changed UTXOs should change, and ver=
ify that.<br><br>Please let me know if I'm wrong or have overlooked any=
specs. Also, let me know if there's anything about this that hasn'=
t been mentioned in the specs yet.<br><br>=E2=80=93<br>Hiroki Gondo<br></di=
v><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">2022=E5=B9=B44=E6=9C=886=E6=97=A5(=E6=B0=B4) 0:06 Ol=
aoluwa Osuntokun <<a href=3D"mailto:laolu32@gmail.com" target=3D"_blank"=
>laolu32@gmail.com</a>>:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr">Hi y'all, <br><br>I'm excited to publi=
cly publish a new protocol I've been working on over the<br>past few mo=
nths: Taro. Taro is a Taproot Asset Representation Overlay which<br>allows =
the issuance of normal and also collectible assets on the main Bitcoin<br>c=
hain. Taro uses the Taproot script tree to commit extra asset structured me=
ta<br>data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle =
Tree or<br>MS-SMT. An MS-SMT combined the properties of a merkle sum tree, =
with a sparse<br>merkle tree, enabling things like easily verifiable asset =
supply proofs and<br>also efficient proofs of non existence (eg: you prove =
to me you're no longer<br>committing to the 1-of-1 holographic beefzard=
card during our swap). Taro asset<br>transfers are then embedded in a virt=
ual/overlay transaction graph which uses a<br>chain of asset witnesses to p=
rovably track the transfer of assets across<br>taproot outputs. Taro also h=
as a scripting system, which allows for<br>programmatic unlocking/transfer =
of assets. In the first version, the scripting<br>system is actually a recu=
rsive instance of the Bitcoin Script Taproot VM,<br>meaning anything that c=
an be expressed in the latest version of Script can be<br>expressed in the =
Taro scripting system. Future versions of the scripting system<br>can intro=
duce new functionality on the Taro layer, like covenants or other<br>update=
s.<br><br>The Taro design also supports integration with the Lightning Netw=
ork (BOLTs) as<br>the scripting system can be used to emulate the existing =
HTLC structure, which<br>allows for multi-hop transfers of Taro assets. Rat=
her than modify the internal<br>network, the protocol proposes to instead o=
nly recognize "assets at the edges",<br>which means that only the=
sender+receiver actually need to know about and<br>validate the assets. Th=
is deployment route means that we don't need to build up<br>an entirely=
new network and liquidity for each asset. Instead, all asset<br>transfers =
will utilize the Bitcoin backbone of the Lightning Network, which<br>means =
that the internal routers just see Bitcoin transfers as normal, and don'=
;t<br>even know about assets at the edges. As a result, increased demand fo=
r<br>transfers of these assets as the edges (say like a USD stablecoin), wh=
ich in<br>will turn generate increased demand of LN capacity, result in mor=
e transfers, and<br>also more routing revenue for the Bitcoin backbone node=
s.<br><br>The set of BIPs are a multi-part suite, with the following breakd=
own:<br>=C2=A0* The main Taro protocol: <a href=3D"https://github.com/Roasb=
eef/bips/blob/bip-taro/bip-taro.mediawiki" target=3D"_blank">https://github=
.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki</a><br>=C2=A0* The MS-S=
MT structure: <a href=3D"https://github.com/Roasbeef/bips/blob/bip-taro/bip=
-taro-ms-smt.mediawiki" target=3D"_blank">https://github.com/Roasbeef/bips/=
blob/bip-taro/bip-taro-ms-smt.mediawiki</a><br>=C2=A0* The Taro VM: <a href=
=3D"https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki" t=
arget=3D"_blank">https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm=
.mediawiki</a><br>=C2=A0* The Taro address format: <a href=3D"https://githu=
b.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki" target=3D"_blank=
">https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki</a=
><br>=C2=A0* The Taro Universe concept: <a href=3D"https://github.com/Roasb=
eef/bips/blob/bip-taro/bip-taro-universe.mediawiki" target=3D"_blank">https=
://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki</a><b=
r>=C2=A0* The Taro flat file proof format: =C2=A0<a href=3D"https://github.=
com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki" target=3D"_b=
lank">https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.me=
diawiki</a><br><br>Rather than post them all in line (as the text wouldn=
9;t fit in the allowed size<br>limit), all the BIPs can be found above.<br>=
<br>-- Laolu<br></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div></div>
</blockquote></div>
--00000000000088f96f05eb5a21eb--
|