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
|
Return-Path: <slashene@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 59110724
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Aug 2016 02:25:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
[209.85.220.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 116BB2A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Aug 2016 02:25:26 +0000 (UTC)
Received: by mail-qk0-f169.google.com with SMTP id l2so3104470qkf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Aug 2016 19:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=0KKIPUBgU2KQaxO2YRMmzybRGoPX5gi0KZapFOUA4F8=;
b=FfDgvpaC7XHoLODqn6klUM0/u2cCRvfBWiUbSXvrnuOUVHt7dwPsTzsdXS45oDSFqQ
JxDVtsZRQPNyEdHBehWM+Kc/jE8JAN/OZ9JIBmRks9GsS03uVYomx2/l2+RbOSNrelCq
z0QbLd8W6wt/VYlhNXhv1s7Jo2omNU25PKeMlJlSZVi6/uDd96icB2Kj55IFLTzuhoWf
qTRhGWGpDYIJ8XRKKCyj853odbhZgYSVHK1Ow4rqP0d8kxerREReLaokCPsi4e9Xxk1+
UkWJfAinQYirHdSN1GYGEOKnb4JsYh5an4DGmxcGHCPOS3ckjk8dVs7f21ihmv+igZC9
RTTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=0KKIPUBgU2KQaxO2YRMmzybRGoPX5gi0KZapFOUA4F8=;
b=mLgxX3+6kSGAnABEYwcrpgnHwRynNrydJfjYB7VA+lEEZof4CQ8YrB3d76GnOCsJKg
IJDaRFadpBn0inVCEm/wksNLwnWzRWJjT9/WhQyUsmY3VZTZD1ZQjJW6bhlPJkoMamK+
d3H3dLzQtVN6DDb63HG+Dymc0GcCw90TQckBD9DQzAgBIwDb9d5QIVUOpkG3sSNZwD93
lNt4rfz9EfDUyc5Xyjlfjpha8KTU94TQ4O+HQh7zKgbj3ZuaVrohua2Ix7ll2jD71KE0
Emho8Z3Xo3FkbvHyLKuSxGdIDf0YWaBU2EOj+vr9F7y1t4w5Z31hfc5uUs7yKVFh9hRq
MYEQ==
X-Gm-Message-State: AEkoouswhCcyY0Dmfi9tS0vETGVRezncoEjhhvRvyBIRYaTwc3FquJV3Jkz/nKDHViSNmt2hwkzRFJhxafGE5w==
X-Received: by 10.55.122.65 with SMTP id v62mr21014252qkc.120.1471055125229;
Fri, 12 Aug 2016 19:25:25 -0700 (PDT)
MIME-Version: 1.0
Sender: slashene@gmail.com
Received: by 10.55.186.5 with HTTP; Fri, 12 Aug 2016 19:25:04 -0700 (PDT)
In-Reply-To: <CABbpET83UAt-TZfQsi0ZyhPAEznucc2yKYA4Md9y78=XH-vpmw@mail.gmail.com>
References: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
<201605260353.06939.luke@dashjr.org>
<20160705174636.GA24068@fedora-21-dvm>
<201607060122.20593.luke@dashjr.org>
<CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
<CA+1nnrmsU5kLxuW=GJSmy8C7s6F3EM8sgFYoXDg1iM-eD2qzsg@mail.gmail.com>
<CAJowKgJys93VTFuGA3ydcuqxcx_O6r0D7715Kgfyc+SP4P8J9A@mail.gmail.com>
<CAE28kUSaTsQ4qyGK5t5D1KiEF3yf4LEjkFvy+SiGxDK5VeAo9Q@mail.gmail.com>
<CABbpET83UAt-TZfQsi0ZyhPAEznucc2yKYA4Md9y78=XH-vpmw@mail.gmail.com>
From: Nicolas Dorier <nicolas.dorier@gmail.com>
Date: Sat, 13 Aug 2016 11:25:04 +0900
X-Google-Sender-Auth: _ilpzlf9BYP4T_Mz7N-fa0zuyKo
Message-ID: <CA+1nnrkXnFjRQ_+wpoOud0-ELqot+UhuG8UswC0EZ9-zWcjwBw@mail.gmail.com>
To: Flavien Charlon <flavien.charlon@coinprism.com>
Content-Type: multipart/alternative; boundary=94eb2c05e0ec2f3ab40539eab66a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Number Request: Open Asset
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sat, 13 Aug 2016 02:25:27 -0000
--94eb2c05e0ec2f3ab40539eab66a
Content-Type: text/plain; charset=UTF-8
I think that regardless of merits protocol or limitations of protocols,
once they become used and stable they merit their place as a BIP.
I'd like to submit OA as is on flavien's repository, and update or reword
things once it is there. (so he can ACK easily and we can keep track of
changes instead of using mails back and forth)
It would be useful to have other colored coin protocols as well. (EPOBC and
Colu)
On Thu, Aug 4, 2016 at 9:37 PM, Flavien Charlon <
flavien.charlon@coinprism.com> wrote:
> Hi,
>
> > I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>
> Alex summarizes the situation well. Efforts to come up with a
> "multiple-colored-coin-protocol" have failed since the different
> protocols take different assumptions and different tradeoffs and are built
> for different use cases. In the end, we ended up exactly in the same
> situation as the well known XKCD comic strip about standards (
> https://xkcd.com/927/).
>
> > You can, however, provide a new OA2.0 protocol that improves upon these
> issues, and assure that upgraded wallets maintain support for both versions.
>
> I don't think there is a point in doing that. This would just result in
> having yet another "standard", which nobody uses. Open Assets 1.0 took 3
> years to get where it is today, and is used by many companies across the
> industry. It has well over 20 different implementations, some open source,
> some proprietary.
>
> The goal of this process is to have OA 1.0 becoming the BIP since this is
> the one people are using.
>
> > I was waiting for clarification on the Author thing, but Nicholas hasn't
> responded yet. I am unaware of any reason NOT to assign it, and there
> appear to be no objections, so let's call it BIP 160.
>
> Nicolas is proposing the BIP on my behalf. I'll ACK as needed but he can
> drive the discussions.
>
> Best,
> Flavien
>
> On Tue, Aug 2, 2016 at 6:25 PM, Alex Mizrahi via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
>>> written by reps from all of the major protocols and that meta-merges the
>>> features of these implementations
>>>
>>
>> We actually tried to do that in 2014-2015, but that effort have failed...
>> Nobody was really interested in collaboration, each company only cared
>> about it's own product.
>> Especially Colu, they asked everyone for requirements, and then developed
>> a new protocol completely on their own without taking anyone's input.
>>
>> I'm not sure that merging the protocols makes sense, as some protocols
>> value simplicity, and a combined protocol cannot have this feature.
>>
>> I don't think there is much interest in a merged colored coin protocol
>> now.
>> Colu is moving away from colored coins, as far as I can tell.
>> CoinSpark is now doing MultiChain closed-source private blockchain.
>> CoinPrism also seems to be largely disinterested in colored coins.
>>
>> We (ChromaWay) won't mind replacing EPOBC with something better, our
>> software could always support multiple different kernels so adding a new
>> protocol isn't a big deal for us.
>>
>> So if somebody is interested in a new protocol please ping me.
>>
>> One of ideas I have is to decouple input-output mapping/multiplexing from
>> coloring.
>> So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into
>> outputs 0, 1 and 2".
>> In this case it will be possible to create more advanced protocols (e.g.
>> with support for 'smart contracts' and whatnot) while also keeping them
>> compatible with old ones to some extent, e.g. a wallet can safely engage in
>> p2ptrade or CoinJoin transactions without understanding all protocols used
>> in a transaction.
>>
>>
>>> - in collaboration with feedback from core developers that understand
>>> the direction the protocol will be taking and the issues to avoid.
>>>
>>
>> Core developers generally dislike things like colored coins, so I doubt
>> they are going to help.
>>
>> Blockstream is developing a sidechain with user-defined assets, so I
>> guess they see it as the preferred way of doing things:
>> https://elementsproject.org/elements/asset-issuance/
>>
>>
>>> As it stands, investors have to install multiple wallets to deal with
>>> these varying implementations.
>>>
>>
>> Actually this can be solved without making a new "merged protocol": one
>> can just implement a wallet which supports multiple protocols.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--94eb2c05e0ec2f3ab40539eab66a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that regardless of merits protocol or limitations =
of protocols, once they become used and stable they merit their place as a =
BIP.<div>I'd like to submit OA as is on flavien's repository, and u=
pdate or reword things once it is there. (so he can ACK easily and we can k=
eep track of changes instead of using mails back and forth)</div><div>It wo=
uld be useful to have other colored coin protocols as well. (EPOBC and Colu=
)</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On T=
hu, Aug 4, 2016 at 9:37 PM, Flavien Charlon <span dir=3D"ltr"><<a href=
=3D"mailto:flavien.charlon@coinprism.com" target=3D"_blank">flavien.charlon=
@coinprism.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>Hi,</div><span class=3D""><div><br></div><div>> I woul=
d love to see an RFC-style standard "multiple-colored-coin-<wbr>protoc=
ol" written by reps from all of the major protocols and that meta-merg=
es the features of these implementations</div><div><br></div></span><div>Al=
ex summarizes the situation well. Efforts to come up with=C2=A0a "mult=
iple-colored-coin-<wbr>protocol" have failed since the different proto=
cols take different assumptions and different tradeoffs and are built for d=
ifferent use cases. In the end, we ended up exactly in the same situation a=
s the well known XKCD comic strip about standards (<a href=3D"https://xkcd.=
com/927/" target=3D"_blank">https://xkcd.com/927/</a>).</div><span class=3D=
""><div><br></div><div>> You can, however, provide a new OA2.0 protocol =
that improves upon these issues, and assure that upgraded wallets maintain =
support for both versions.</div><div><br></div></span><div>I don't thin=
k there is a point in doing that. This would just result in having yet anot=
her "standard", which nobody uses. Open Assets 1.0 took 3 years t=
o get where it is today, and is used by many companies across the industry.=
It has well over 20 different implementations, some open source, some prop=
rietary.</div><div><br></div><div>The goal of this process is to have OA 1.=
0 becoming the BIP since this is the one people are using.</div><span class=
=3D""><div><br></div><div>> I was waiting for clarification on the Autho=
r thing, but Nicholas hasn't responded yet. I am unaware of any reason =
NOT to assign it, and there appear to be no objections, so let's call i=
t BIP 160.</div><div><br></div></span><div>Nicolas is proposing the BIP on =
my behalf. I'll=C2=A0ACK as needed but he can drive the discussions.<br=
></div><div><br></div><div>Best,</div><div>Flavien</div></div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Tue,=
Aug 2, 2016 at 6:25 PM, Alex Mizrahi via bitcoin-dev <span dir=3D"ltr"><=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> wrote:<br></div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div><div><div><div>I would love to see an RFC-style s=
tandard "multiple-colored-coin-<wbr>protocol" written by reps fro=
m all of the major protocols and that meta-merges the features of these imp=
lementations</div></div></div></div></div></blockquote><div><br></div></spa=
n><div>We actually tried to do that in 2014-2015, but that effort have fail=
ed...</div><div>Nobody was really interested in collaboration, each company=
only cared about it's own product.</div><div>Especially Colu, they ask=
ed everyone for requirements, and then developed a new protocol completely =
on their own without taking anyone's input.</div><div><br></div><div>I&=
#39;m not sure that merging the protocols makes sense, as some protocols va=
lue simplicity, and a combined protocol cannot have this feature.</div><div=
><br></div><div>I don't think there is much interest in a merged colore=
d coin protocol now.</div><div>Colu is moving away from colored coins, as f=
ar as I can tell.</div><div>CoinSpark is now doing MultiChain closed-source=
private blockchain.</div><div>CoinPrism also seems to be largely disintere=
sted in colored coins.</div><div><br></div><div>We (ChromaWay) won't mi=
nd replacing EPOBC with something better, our software could always support=
multiple different kernels so adding a new protocol isn't a big deal f=
or us.</div><div><br></div><div>So if somebody is interested in a new proto=
col please ping me.</div><div><br></div><div>One of ideas I have is to deco=
uple input-output mapping/multiplexing from coloring.</div><div>So one laye=
r will describe a mapping, e.g. "Inputs 0 and 1 should go into outputs=
0, 1 and 2".</div><div>In this case it will be possible to create mor=
e advanced protocols (e.g. with support for 'smart contracts' and w=
hatnot) while also keeping them compatible with old ones to some extent, e.=
g. a wallet can safely engage in p2ptrade or CoinJoin transactions without =
understanding all protocols used in a transaction.</div><span><div>=C2=A0<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div><div> - in collabo=
ration with feedback from core developers that understand the direction the=
protocol will be taking and the issues to avoid.=C2=A0=C2=A0 </div></div><=
/div></div></div></blockquote><div><br></div></span><div>Core developers ge=
nerally dislike things like colored coins, so I doubt they are going to hel=
p.</div><div><br></div><div>Blockstream is developing a sidechain with user=
-defined assets, so I guess they see it as the preferred way of doing thing=
s:</div><div><a href=3D"https://elementsproject.org/elements/asset-issuance=
/" target=3D"_blank">https://elementsproject.org/<wbr>elements/asset-issuan=
ce/</a><br></div><span><div>=C2=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div>As it stands, investors have to install multiple wallets to deal wi=
th these varying implementations.</div></div></blockquote><div><br></div></=
span><div>Actually this can be solved without making a new "merged pro=
tocol": one can just implement a wallet which supports multiple protoc=
ols.</div><div><br></div><div><br></div></div></div></div>
<br></div></div><span class=3D"">______________________________<wbr>_______=
__________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
--94eb2c05e0ec2f3ab40539eab66a--
|