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; 
MIME-Version: 1.0
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
Subject: [Bitcoin-development] Feedback request: colored coins protocol
Precedence: list

--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&#39;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&#39;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&#39;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&#39;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--