From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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 Date: Sun, 6 Apr 2014 21:59:34 +0100 Message-ID: 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 ] -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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 , 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
Hi,

I am the lead developer = of Coinprism, = 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.

I am looking for feedback/discussions regarding the pro= tocol 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 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.


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.

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.
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).

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.

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.

Do you think this is the right approach?

=
Feel free to reply with any feedback regarding the protocol.

Thanks,
Flavien
--14dae94edbd3983ea604f666096f--