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
|
Return-Path: <laolu32@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0CE3DC002C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Apr 2022 18:21:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id E69F141525
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Apr 2022 18:21:29 +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 AS_WLbVAfmSI
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Apr 2022 18:21:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com
[IPv6:2a00:1450:4864:20::433])
by smtp4.osuosl.org (Postfix) with ESMTPS id 01C4E41519
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Apr 2022 18:21:27 +0000 (UTC)
Received: by mail-wr1-x433.google.com with SMTP id s28so8350751wrb.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Apr 2022 11:21:27 -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;
bh=5jV83CnLsh9hxDgbO3HaZSjwoHG+a0FHWp5IqP7twKk=;
b=F4d9CUQSJB3V4Z+tJhhHlYei1HuxflSKczgDZ7XM2dKgLbRuU3Whx9+We3njd7elRF
0YERWD5Dk04sFY5BUzLGGqw7D3oXzb5S7fujAkXEbQ92OzlOVNUWn7Xmol7e2yXm5oTJ
O4n+wkjEO+VEEWsMB7vE1aVGn1XBU1qH5TGbPmZJpnyYx/k4Syp/j6aVHt5ybjRSYMr0
hsbcI7khRV8iudKOESsOV2ydcL2dSlpKEXyj20Qw+LqrNYGJX/tLYg1Xe8rXcAf+Bb9k
DpavzouJjz9HjtbrITiH+Bky3OGI5OJScKL8RkJpQ5jSxkTKo4XvjitwN/c3PuxqvzT4
c1xg==
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=5jV83CnLsh9hxDgbO3HaZSjwoHG+a0FHWp5IqP7twKk=;
b=IxCT2gaNaDrI/i7NQgz+ECT1vsL7mO/zUhqv/KXDnSL8S6Sxw/is8oPkJYJi1AqP1V
fyq6m0ISiBagPQU72cqOwGYVWNxr9af+iQvWd4669gzJucaGbYaFzwCWdvgwEyJYXOAg
UPpT24599yj7ZMwFls9wfdU2iIP+adi94iPdqddpsDAxwcs3aGj4Jk9F6YK1snk83o+v
dDR78kEr+SD2aWs6p/x/zjYh8NHJMF6vUvpcFmygcjSl+mYRI7EkHob8xJkE8eh2yGbj
H35OX7Ambd/+igRvONRZOVxAZOMsRwnUhff7Xj0h+xeQfLj2ihftu1rRaupW/ZRHmRYR
Uo+g==
X-Gm-Message-State: AOAM531wKBpW+WUbjwxxJ2C7pTDvbPan5iSbIfq4TtG8fDqIToFNFHp6
B/Vb8wLDyG+7OVfCxSDQdUfivD83jv1t4x4i6IE=
X-Google-Smtp-Source: ABdhPJwKUG5RIYB/FxpQ3cX5y1kx2G95uEmycM3fVIeGKidkPY+6NbaXtSWQbZSiWjCWYWmINwAlalSV+/UuVYY9WIs=
X-Received: by 2002:adf:910d:0:b0:1e3:9484:1601 with SMTP id
j13-20020adf910d000000b001e394841601mr24758931wrj.419.1649701285913; Mon, 11
Apr 2022 11:21:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAHUJnBCwkVA1etjBDLDCcfCJvVfKePzNCO0NYt=qMT8HL4PxJw@mail.gmail.com>
In-Reply-To: <CAHUJnBCwkVA1etjBDLDCcfCJvVfKePzNCO0NYt=qMT8HL4PxJw@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Mon, 11 Apr 2022 14:21:14 -0400
Message-ID: <CAO3Pvs_MPLWb+8HMzJ4XgVvh_wzUgPpGpnciNCEyryDdUZi6YQ@mail.gmail.com>
To: Bram Cohen <bram@chia.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000021e88305dc650327"
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 18:21:30 -0000
--00000000000021e88305dc650327
Content-Type: text/plain; charset="UTF-8"
Hi Bram,
> The witnesses for transactions need to be put into Bitcoin transactions
> even though the Bitcoin layer doesn't understand them
Is this related to Ruben's comment about invalid state transitions
(published in the base chain) leading to burned assets? In the past, I've
considered using the existing annex field in taproot transactions to
implement partial reveal of certain data. However, today bitcoind treats
annex usage as non-standard, so those transactions may be harder to relay.
IMO this is a great place to add minimal extra data, as it doesn't bleed
over into
the scripting layer (via OP_DROP usages) and since Bitcoin-level signatures
also include this field in the sighash, the sigs serve to further
authenticate this data.
Future op codes that allow Scripts to push annex data onto the stack could
also be used to further bind higher level protocols while still allowing the
base Bitcoin consensus rules to not have to be explicitly aware of them.
> Taro issuance is limited to a single event rather than potentially
> multiple events over time subject to special per-asset rules.
There's a provision in the protocol that lets a party issuing assets to
specify a special public key which is then tweaked with the genesis
outpoint, similar to the way the asset IDs are generated. If this key is
specified, then future issuance, if signed off by that key, will serve to
associate assets of discrete IDs under a single identifier. This feature
allows assets issued in multiple tranches to be fungible with one another.
> but I am puzzled by the announcement saying Taro assets are 'analogous
> with' colored coins. Taro assets are straightforwardly and unambiguously
> colored coins and that isn't something to be ashamed of.
We've shied away from using the "colored coins' terminology as at this point
in the game it's pretty dated: new developers that joined in the last 3
years or so have likely never heard of that term. Explaining the term also
requires one to define "coin coloring", and what that actually means, etc,
etc. IMO it's simpler to just use the familiar and widely used asset
issuance/minting terminology.
-- Laolu
On Sun, Apr 10, 2022 at 9:10 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> From: Olaoluwa Osuntokun <laolu32@gmail.com>
>
>>
>> > Furthermore, the Taro script is not enforced by Bitcoin, meaning those
>> who
>> > control the Bitcoin script can always choose to ignore the Taro script
>> and
>> > destroy the Taro assets as a result.
>>
>> This is correct, as a result in most contexts, an incentive exists for the
>> holder of an asset to observe the Taro validation rules as otherwise,
>> their
>> assets are burnt in the process from the PoV of asset verifiers. In the
>> single
>> party case things are pretty straight forward, but more care needs to be
>> taken
>> in cases where one attempts to express partial application and permits
>> anyone
>> to spend a UTXO in question.
>>
>> By strongly binding all assets to Bitcoin UTXOs, we resolve issues related
>> to
>> double spending or duplicate assets, but needs to mind the fact that
>> assets
>> can
>> be burnt if a user doesn't supply a valid witness. There're likely ways to
>> get
>> around this by lessening the binding to Bitcoin UTXO's, but then the
>> system
>> would need to be able to collect, retain and order all the set of possible
>> spends, essentially requiring a parallel network. The core of the system
>> as
>> it
>> stands today is pretty simple (which was an explicit design goal to avoid
>> getting forever distracted by the large design space), with a minimal
>> implementation being relatively compact given all the Bitcoin
>> context/design
>> re-use.
>>
>
> The TARO set of tradeoffs is fairly coherent but is subject to certain
> limitations (modulo my understanding of it being off):
>
> The witnesses for transactions need to be put into Bitcoin transactions
> even though the Bitcoin layer doesn't understand them
>
> There needs to be a constraint on Taro transactions which is understood by
> the Bitcoin layer (which often/usually happens naturally because there's a
> user signature but sometimes doesn't. It's a limitation)
>
> Multiple Taro coins can't consolidate their value into a single output
> because they only support a single linear history
>
> Taro issuance is limited to a single event rather than potentially
> multiple events over time subject to special per-asset rules.
>
> This seems like a fairly logical approach (although my understanding of
> the limitations/tradeoffs could be wrong, especially with regards to
> consolidation). There's nothing wrong with a system having well documented
> limitations, but I am puzzled by the announcement saying Taro assets are
> 'analogous with' colored coins. Taro assets are straightforwardly and
> unambiguously colored coins and that isn't something to be ashamed of.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000021e88305dc650327
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Hi Bram, <br><br>> The witnesses for t=
ransactions need to be put into Bitcoin transactions<br>> even though th=
e Bitcoin layer doesn't understand them<br><br>Is this related to Ruben=
's comment about invalid state transitions<br>(published in the base ch=
ain) leading to burned assets? In the past, I've<br>considered using th=
e existing annex field in taproot transactions to<br>implement partial reve=
al of certain data. However, today bitcoind treats<br>annex usage as non-st=
andard, so those transactions may be harder to relay.<br>IMO this is a grea=
t place to add minimal extra data, as it doesn't bleed over into<br>the=
scripting layer (via OP_DROP usages) and since Bitcoin-level signatures<br=
>also include this field in the sighash, the sigs serve to further<br>authe=
nticate this data.<br><br>Future op codes that allow Scripts to push annex =
data onto the stack could<br>also be used to further bind higher level prot=
ocols while still allowing the<br>base Bitcoin consensus rules to not have =
to be explicitly aware of them.<br><br>> Taro issuance is limited to a s=
ingle event rather than potentially<br>> multiple events over time subje=
ct to special per-asset rules.<br><br>There's a provision in the protoc=
ol that lets a party issuing assets to<br>specify a special public key whic=
h is then tweaked with the genesis<br>outpoint, similar to the way the asse=
t IDs are generated. If this key is<br>specified, then future issuance, if =
signed off by that key, will serve to<br>associate assets of discrete IDs u=
nder a single identifier. This feature<br>allows assets issued in multiple =
tranches to be fungible with one another.<br><br>> but I am puzzled by t=
he announcement saying Taro assets are 'analogous<br>> with' col=
ored coins. Taro assets are straightforwardly and unambiguously<br>> col=
ored coins and that isn't something to be ashamed of.<br><br>We've =
shied away from using the "colored coins' terminology as at this p=
oint<br>in the game it's pretty dated: new developers that joined in th=
e last 3<br>years or so have likely never heard of that term. Explaining th=
e term also<br>requires one to define "coin coloring", and what t=
hat actually means, etc,<br>etc. IMO it's simpler to just use the famil=
iar and widely used asset<br>issuance/minting terminology.<br><br>-- Laolu<=
br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Sun, Apr 10, 2022 at 9:10 PM Bram Cohen via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<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"><div dir=3D"ltr">From: Olaoluwa Osuntokun <=
<a href=3D"mailto:laolu32@gmail.com" target=3D"_blank">laolu32@gmail.com</a=
>><br></div><div class=3D"gmail_quote"><div><div style=3D"margin:5px 0px=
"><div id=3D"gmail-m_-3661149741623974162gmail-q_10" aria-label=3D"Hide exp=
anded content" aria-expanded=3D"true" style=3D"background-color:rgb(232,234=
,237);border:none;clear:both;line-height:6px;outline:none;width:24px;color:=
rgb(80,0,80);font-size:11px;border-radius:5.5px"><div style=3D"background:u=
rl("https://www.gstatic.com/images/icons/material/system_gm/2x/more_ho=
riz_black_20dp.png") 50% 50%/20px no-repeat;height:11px;opacity:0.71;w=
idth:24px"></div></div></div><div style=3D"color:rgb(80,0,80)"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><br>> Furthermore, the Taro script=
is not enforced by Bitcoin, meaning those who<br>> control the Bitcoin =
script can always choose to ignore the Taro script and<br>> destroy the =
Taro assets as a result.<br><br>This is correct, as a result in most contex=
ts, an incentive exists for the<br>holder of an asset to observe the Taro v=
alidation rules as otherwise, their<br>assets are burnt in the process from=
the PoV of asset verifiers. In the<br>single<br>party case things are pret=
ty straight forward, but more care needs to be<br>taken<br>in cases where o=
ne attempts to express partial application and permits<br>anyone<br>to spen=
d a UTXO in question.<br><br>By strongly binding all assets to Bitcoin UTXO=
s, we resolve issues related<br>to<br>double spending or duplicate assets, =
but needs to mind the fact that assets<br>can<br>be burnt if a user doesn&#=
39;t supply a valid witness. There're likely ways to<br>get<br>around t=
his by lessening the binding to Bitcoin UTXO's, but then the system<br>=
would need to be able to collect, retain and order all the set of possible<=
br>spends, essentially requiring a parallel network. The core of the system=
as<br>it<br>stands today is pretty simple (which was an explicit design go=
al to avoid<br>getting forever distracted by the large design space), with =
a minimal<br>implementation being relatively compact given all the Bitcoin =
context/design<br>re-use.<br></blockquote><div><br></div></div></div><div>T=
he TARO set of tradeoffs is fairly coherent but is subject to certain limit=
ations (modulo my understanding of it being off):</div><div><br></div><div>=
The witnesses for transactions need to be put into Bitcoin transactions eve=
n though the Bitcoin layer doesn't understand them</div><div><br></div>=
<div>There needs to be a constraint on Taro transactions which is understoo=
d by the Bitcoin layer (which often/usually happens naturally because there=
's a user signature but sometimes doesn't. It's a limitation)</=
div><div><br></div><div>Multiple Taro coins can't consolidate their val=
ue into a single output because they only support a single linear history</=
div><div><br></div><div>Taro issuance is limited to a single event rather t=
han potentially multiple events over time subject to special per-asset rule=
s.</div><div><br></div><div>This seems like a fairly logical approach (alth=
ough my understanding of the limitations/tradeoffs could be wrong, especial=
ly with regards to consolidation). There's nothing wrong with a system =
having well documented limitations, but I am puzzled by the announcement sa=
ying Taro assets are 'analogous with' colored coins. Taro assets ar=
e straightforwardly and unambiguously colored coins and that isn't some=
thing to be ashamed of.</div></div></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>
--00000000000021e88305dc650327--
|