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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <flavien.charlon@pixodegames.com>) id 1WWue8-0000Kr-At
for bitcoin-development@lists.sourceforge.net;
Sun, 06 Apr 2014 21:30:32 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of
pixodegames.com designates 209.85.215.52 as permitted sender)
client-ip=209.85.215.52;
envelope-from=flavien.charlon@pixodegames.com;
helo=mail-la0-f52.google.com;
Received: from mail-la0-f52.google.com ([209.85.215.52])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WWue6-0003zJ-Sr
for bitcoin-development@lists.sourceforge.net;
Sun, 06 Apr 2014 21:30:32 +0000
Received: by mail-la0-f52.google.com with SMTP id ec20so3993739lab.25
for <bitcoin-development@lists.sourceforge.net>;
Sun, 06 Apr 2014 14:30:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-type;
bh=QT2rw592nADlXZ30daKGX+5HWdO3V4CUBb51RTmkRh4=;
b=c7KkO34EoE3W0f+HaHOz/CtcCC0qCiVcijkgK1BOe8H9vryMneuU6E3+TlwWN6234T
wIuqGxhZaiFED/hgB0JnwRd4n3EtVZXnpAmsl9/ZoXWCzgdXrydQIcKYjZafy0h1rJI0
LjyIyEoERBmTgwl8HV5qggKMhkbLCAjt2govo3FlAHATQ0DQNfypAGJ82oHOkviwdkX9
yp4LFQICFLikGjbsb50ovazsZe1DKGWKrOWtlRGEaUo8W1TTBuwZWkXRlFJx9YHkPvAi
mT0PZlb+loKmfkjbr0Lfi1EeGwJ04/O18J6BSk7wrcGoGIfbzUJdKmsraQhrPnpKfoVL
f2hw==
X-Gm-Message-State: ALoCoQkRqZvCbSTcvo8TYHDz/kc1BHy6mocwA/U8QFNTa//x9NZShBOmpj1kt61CTEkqTpQTstH/
X-Received: by 10.152.22.72 with SMTP id b8mr463510laf.63.1396818015435;
Sun, 06 Apr 2014 14:00:15 -0700 (PDT)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com
[209.85.215.50]) by mx.google.com with ESMTPSA id
v20sm10427118lbi.24.2014.04.06.14.00.15
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 06 Apr 2014 14:00:15 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id pv20so4163470lab.9
for <bitcoin-development@lists.sourceforge.net>;
Sun, 06 Apr 2014 14:00:14 -0700 (PDT)
X-Received: by 10.112.1.233 with SMTP id 9mr2720564lbp.29.1396818014906; Sun,
06 Apr 2014 14:00:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.185.230 with HTTP; Sun, 6 Apr 2014 13:59:34 -0700 (PDT)
X-Originating-IP: [90.20.14.129]
From: Flavien Charlon <flavien.charlon@coinprism.com>
Date: Sun, 6 Apr 2014 21:59:34 +0100
Message-ID: <CABbpET96CboPcQeV-nKXv-CeaPiwpTKVUB_ioGPB2s3_5Y7bnQ@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=14dae94edbd3983ea604f666096f
X-Spam-Score: 2.1 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see <http://www.spamcop.net/bl.shtml?209.85.215.50>]
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
1.5 SF_NO_SPF_SPAM SF_NO_SPF_SPAM
X-Headers-End: 1WWue6-0003zJ-Sr
Subject: [Bitcoin-development] Feedback request: colored coins protocol
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 06 Apr 2014 21:30:32 -0000
--14dae94edbd3983ea604f666096f
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I am the lead developer of Coinprism <https://www.coinprism.com/>, the new
colored coins web wallet. After some discussions with the other people
involved with colored coins, I wrote a specification document describing
the colored coins protocol that we are using in coinprism.
I am looking for feedback/discussions regarding the protocol before we move
from TestNet to MainNet. The document is here:
https://github.com/Flavien/colored-coins-protocol/blob/master/specification.mediawiki
.
The colored coin protocol is layered on top of the existing Bitcoin
protocol and requires no modification of the existing protocol, so it can
be used today. This means that SPV is not as efficient, as the client needs
to backtrack up to the issuing transaction to find the color of an output,
but that is something we can live with.
The protocol marks transactions either as issuance or transfer transactions
by using an OP_RETURN output with a 9 bytes marker. The protocol uses the
value of an output as the colored value. So if an output has 1 BTC and is
colored with color A, that means we have 1 BTC colored with color A.
An alternative would have been to completely disconnect the colored value
and the real BTC value. The colored value of each output would be encoded
in an OP_RETURN output. Someone who wants to send 1000 colored coins would
craft a transaction with an output with the smallest possible amount of BTC
(5,400 satoshis) and indicate in the OP_RETURN that they are sending 1000
colored coins.
The two reasons why we haven't chosen that approach is that first, this
only works with a limited number of outputs given that we have only 40
bytes. And second, this could lead to people spamming the network with very
small outputs (but containing an arbitrary number of colored coins).
On the other hand, with the approach we're using (colored value = actual
value of the output), the 5,400 satoshis rule means that the smallest unit
of colored coin you can send is 5,400 satoshis.
If you want to issue 1 million shares, while still being able to trade each
share individually, you'd have to set 1 share = 5,400 satoshis, and you
would need a capital of 54 BTC for issuing a million shares. It's not a big
problem in itself, but still a slight inconvenience.
Do you think this is the right approach?
Feel free to reply with any feedback regarding the protocol.
Thanks,
Flavien
--14dae94edbd3983ea604f666096f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I am the lead developer =
of <a href=3D"https://www.coinprism.com/" target=3D"_blank">Coinprism</a>, =
the new colored coins web wallet. After some discussions with the other peo=
ple involved with colored coins, I wrote a specification document describin=
g the colored coins protocol that we are using in coinprism.</div>
<div><br></div><div>I am looking for feedback/discussions regarding the pro=
tocol before we move from TestNet to MainNet. The document is here: <a href=
=3D"https://github.com/Flavien/colored-coins-protocol/blob/master/specifica=
tion.mediawiki" target=3D"_blank">https://github.com/Flavien/colored-coins-=
protocol/blob/master/specification.mediawiki</a>.</div>
<div><br></div><div>The colored coin protocol is layered on top of the exis=
ting Bitcoin protocol and requires no modification of the existing protocol=
, so it can be used today.=A0This means that SPV is not as efficient, as th=
e client needs to backtrack up to the issuing transaction to find the color=
of an output, but that is something we can live with.</div>
<div><br></div><div><br></div><div>The protocol marks transactions either a=
s issuance or transfer transactions by using an OP_RETURN output with a 9 b=
ytes marker. The protocol uses the value of an output as the colored value.=
So if an output has 1 BTC and is colored with color A, that means we have =
1 BTC colored with color A.</div>
<div><br>
</div><div>An alternative would have been to completely disconnect the colo=
red value and the real BTC value. The colored value of each output would be=
encoded in an OP_RETURN output. Someone who wants to send 1000 colored coi=
ns would craft a transaction with an output with the smallest possible amou=
nt of BTC (5,400 satoshis) and=A0indicate in the OP_RETURN that they are se=
nding 1000 colored coins.</div>
<div>The two reasons why we haven't chosen that approach is that first,=
this only works with a limited number of outputs given that we have only 4=
0 bytes. And second, this could lead to people spamming the network with ve=
ry small outputs (but containing an arbitrary number of colored coins).</di=
v>
<div><br></div><div>On the other hand, with the approach we're using (c=
olored value =3D actual value of the output), the 5,400 satoshis rule means=
that the smallest unit of colored coin you can send is 5,400 satoshis.</di=
v>
<div><br></div><div>If you want to issue 1 million shares, while still bein=
g able to trade each share individually, you'd have to set 1 share =3D =
5,400 satoshis, and you would need a capital of 54 BTC for issuing a millio=
n shares. It's not a big problem in itself, but still a slight inconven=
ience.</div>
<div><br></div><div>Do you think this is the right approach?</div><div><br>=
</div><div>Feel free to reply with any feedback regarding the protocol.</di=
v><div><br></div><div>Thanks,</div><div>Flavien</div></div>
--14dae94edbd3983ea604f666096f--
|
