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
|
Return-Path: <alex.mizrahi@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1BC8594D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Aug 2016 17:25:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
[209.85.220.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BFB262C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Aug 2016 17:25:51 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id v123so48368898qkh.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 02 Aug 2016 10:25:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=eRHBqlGi62JHgxp6PHbX7NVOe8INMNTcFpRmnNn7F0Y=;
b=CROQAirG5GivzynZ/+1vwdWFw4R+mVPsCaDihG43D5tJXIXEC11Je9QaSSBM/e9OmA
zhlOjDBeVdqvyzO+H4GzoyRxQWc7ZD63oA0vZL456Ctcs0huNh3gWJezvOjYO+/GKMVg
7c89k3/kQY18gfXMLIZ6HDUY9GxEURYvQhhqYP/1zBQSeyGwts1TejeGRHDCsmTSwKb1
EuyzEzuX50xbONBGWtpGLaj1HMGdvMq1OzCcjlGyX4JhmLlNiH4fD8ecMdaa+QJ696ip
v3KwHPXZaUCj9CkFNw5jBKEtQ1qg4zluMbetiUsh6nm001mX4/vHGxmFpkXeEP5BZRsE
aMfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=eRHBqlGi62JHgxp6PHbX7NVOe8INMNTcFpRmnNn7F0Y=;
b=Wu3XtuBoUt+9fgQZv67MM/LCCW9vrrSAMRXJ+r4QZDHEUlmSiZgmW6eVq8Xfz+UEar
wIUpy6Ps1sBVaZPGIg0xiQNyXXl/TKun9j3H8m7iKwC0eiXQzGA62ogFfoXk+4TdcWqz
tIRaIGKf0K40ZyJ1gnm0IXprxZnjEP3fqWN5O41OBA1qnNs0Noh8nmYPejKOqdx68neL
MzqyM1vKum1xUkrH5DZ8QykryGL8G1v6xbCybFm7rCgoIXrHvfYCLvPeZLvHKLjFB8sV
euqGI7DQi31faxTVCDq/9Wr1EcXsLYnBC4ptKNgJ8DbxQWCBDkd3UNMr43AWGK4xRigf
4quA==
X-Gm-Message-State: AEkoous/jD/0Roze8gMRXevee5r1JwJ4SjG0JxeEogw1U8pQDWVx/jOf0Uq5BLGXsznDcOz+p7o4V8uT9m8dWA==
X-Received: by 10.55.207.87 with SMTP id e84mr27031197qkj.161.1470158750980;
Tue, 02 Aug 2016 10:25:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.26.9 with HTTP; Tue, 2 Aug 2016 10:25:50 -0700 (PDT)
In-Reply-To: <CAJowKgJys93VTFuGA3ydcuqxcx_O6r0D7715Kgfyc+SP4P8J9A@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>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
Date: Tue, 2 Aug 2016 20:25:50 +0300
Message-ID: <CAE28kUSaTsQ4qyGK5t5D1KiEF3yf4LEjkFvy+SiGxDK5VeAo9Q@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1145b8e61dc0cc05391a0282
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: Nicolas Dorier <nicolas.dorier@gmail.com>
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: Tue, 02 Aug 2016 17:25:53 -0000
--001a1145b8e61dc0cc05391a0282
Content-Type: text/plain; charset=UTF-8
>
> 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.
--001a1145b8e61dc0cc05391a0282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote 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,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div><div><div>I would love to see an RF=
C-style standard "multiple-colored-coin-protocol" written by reps=
from all of the major protocols and that meta-merges the features of these=
implementations</div></div></div></div></div></blockquote><div><br></div><=
div>We actually tried to do that in 2014-2015, but that effort have failed.=
..</div><div>Nobody was really interested in collaboration, each company on=
ly cared about it's own product.</div><div>Especially Colu, they asked =
everyone for requirements, and then developed a new protocol completely on =
their own without taking anyone's input.</div><div><br></div><div>I'=
;m not sure that merging the protocols makes sense, as some protocols value=
simplicity, and a combined protocol cannot have this feature.</div><div><b=
r></div><div>I don't think there is much interest in a merged colored c=
oin protocol now.</div><div>Colu is moving away from colored coins, as far =
as I can tell.</div><div>CoinSpark is now doing MultiChain closed-source pr=
ivate blockchain.</div><div>CoinPrism also seems to be largely disintereste=
d in colored coins.</div><div><br></div><div>We (ChromaWay) won't mind =
replacing EPOBC with something better, our software could always support mu=
ltiple different kernels so adding a new protocol isn't a big deal for =
us.</div><div><br></div><div>So if somebody is interested in a new protocol=
please ping me.</div><div><br></div><div>One of ideas I have is to decoupl=
e input-output mapping/multiplexing from coloring.</div><div>So one layer w=
ill 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 more a=
dvanced protocols (e.g. with support for 'smart contracts' and what=
not) while also keeping them compatible with old ones to some extent, e.g. =
a wallet can safely engage in p2ptrade or CoinJoin transactions without und=
erstanding all protocols used in a transaction.</div><div>=C2=A0<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div><div><div><div> - in collaboration wi=
th 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></di=
v></div></blockquote><div><br></div><div>Core developers generally dislike =
things like colored coins, so I doubt they are going to help.</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 things:</div><div><a =
href=3D"https://elementsproject.org/elements/asset-issuance/">https://eleme=
ntsproject.org/elements/asset-issuance/</a><br></div><div>=C2=A0<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div>As it stands, investors have to insta=
ll multiple wallets to deal with these varying implementations.</div></div>=
</blockquote><div><br></div><div>Actually this can be solved without making=
a new "merged protocol": one can just implement a wallet which s=
upports multiple protocols.</div><div><br></div><div><br></div></div></div>=
</div>
--001a1145b8e61dc0cc05391a0282--
|
