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 1WYbJ7-00079Z-VN for bitcoin-development@lists.sourceforge.net; Fri, 11 Apr 2014 13:15:50 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of pixodegames.com designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; envelope-from=flavien.charlon@pixodegames.com; helo=mail-la0-f47.google.com; Received: from mail-la0-f47.google.com ([209.85.215.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WYbJ6-0006Sz-JB for bitcoin-development@lists.sourceforge.net; Fri, 11 Apr 2014 13:15:49 +0000 Received: by mail-la0-f47.google.com with SMTP id pn19so3436167lab.20 for ; Fri, 11 Apr 2014 06:15:41 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=prL+xFtmrZZvj9OgoSIus2R6Z/awkIULOS/MLDRPeJI=; b=WoNx0T77PZ8xdc+ho67VFtIqh6/VbOwIiJ6WQY+P5FCt1VIAb66EcYGlluFycdC9So 6Yyet4id9wX8wWr48omebu05i3PJW1z8ZotdxGjT5X2I4n8lScZrY1IJP1FC37vGo06B nxqwKyEcS8VCwk5jzi7pVvg1cZmBjP8DPIZgmdzGMR3hl+MN1Nz24HVBx5Y5fVmkkQqc /rhSGBWQiIdNa6P88CHhgT5STaLTdfRO8R6WktllLDlGgs1XafgyZxQ4SccMQAJO07sv xc1aYdwiPBkk0sPetWaBlpxCA37jp6g3bi4C+rgSXSS7cvYRW/JP2uVuFk+jocjaCN78 f75Q== X-Gm-Message-State: ALoCoQk6FtPKoiEBHrk7ku/oF7PXvu3cHI7LxarfX8nD0qsTx8eKBGTUjE+ezzMgjMqu9Wy7+5wR X-Received: by 10.112.61.199 with SMTP id s7mr329154lbr.25.1397220711478; Fri, 11 Apr 2014 05:51:51 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx.google.com with ESMTPSA id cq4sm7149340lad.5.2014.04.11.05.51.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 05:51:50 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id n15so3485936lbi.13 for ; Fri, 11 Apr 2014 05:51:50 -0700 (PDT) X-Received: by 10.152.21.200 with SMTP id x8mr984817lae.58.1397220710633; Fri, 11 Apr 2014 05:51:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.185.230 with HTTP; Fri, 11 Apr 2014 05:51:10 -0700 (PDT) X-Originating-IP: [2a01:110:8:1003:494e:7ce7:f38e:659a] In-Reply-To: References: <5341E1FF.7080204@monetize.io> <5342BEE0.3050204@monetize.io> <5346CDD4.8050206@monetize.io> From: Flavien Charlon Date: Fri, 11 Apr 2014 13:51:10 +0100 Message-ID: To: Alex Mizrahi Content-Type: multipart/alternative; boundary=089e0158aef421664404f6c3ccfb X-Spam-Score: -0.6 (/) 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 -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 X-Headers-End: 1WYbJ6-0006Sz-JB Cc: Bitcoin Dev Subject: Re: [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: Fri, 11 Apr 2014 13:15:50 -0000 --089e0158aef421664404f6c3ccfb Content-Type: text/plain; charset=ISO-8859-1 I have updated the spec . > This is an interesting approach, but OP_RETURN size limitations can be a significant problem for some kinds of applications. This is correct, the number of colored outputs you can have per transaction is limited by OP_RETURN's 40 bytes. We use a compact format (LEB128) for the asset quantity of each output to mitigate that. Assuming you're transferring small amounts of colored coins, you could have up to about 30 colored ouputs. It should work for a decentralized exchange (you only really need 2 or 3 colored outputs). Applications like sending dividends in colored coins however may require splitting into several smaller transactions, but I believe that's an acceptable limitation. On Thu, Apr 10, 2014 at 6:24 PM, Alex Mizrahi wrote: > > >> At this point, I don't think what you are doing is even colored coins >> anymore. You might want to look into Counterparty or Mastercoin. >> > > Nope, it's still colored coins. The difference between colored coin model > and Mastercoin model is that colored coins are linked to transaction > outputs, while Mastercoin has a notion of address balances. > > The implications of this is that in colored coin model explicit > dependencies allow us to rely on SPV. (Assuming that one can fetch the > dependency graph to link txout in question to genesis.) > While it is not the case with Mastercoin. > > While it's pretty far from the original colored coins model, what Flavien > have described is identical to it in majority of aspects. > > This is an interesting approach, but OP_RETURN size limitations can be a > significant problem for some kinds of applications. > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e0158aef421664404f6c3ccfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have updated the spec.

> This is an interesting approach, but OP_RETURN= size limitations can be a significant problem for some kinds of applicatio= ns.

This is correct, the number of colored outputs you can = have per transaction is limited by=A0OP_RETURN's 40 bytes. We use a com= pact format (LEB128) fo= r the asset quantity of each output to mitigate that. Assuming you're t= ransferring small amounts of colored coins, you could have up to about 30 c= olored ouputs.

It should work for a decentralized exchange (you only r= eally need 2 or 3 colored outputs). Applications like sending dividends in = colored coins however may require splitting into several smaller transactio= ns, but I believe that's an acceptable limitation.


On Thu,= Apr 10, 2014 at 6:24 PM, Alex Mizrahi <alex.mizrahi@gmail.com>= ; wrote:
=
=A0
At this point, I don't think what you are doing is even colored c= oins
anymore. You might want to look into Counterparty or Mastercoin.

Nope, it's still colored coins. The dif= ference between colored coin model and Mastercoin model is that colored coi= ns are linked to transaction outputs, while Mastercoin has a notion of addr= ess balances.

The implications of this is that in colored coin model = explicit dependencies allow us to rely on SPV. (Assuming that one can fetch= the dependency graph to link txout in question to genesis.)=A0
While it is not the case with Mastercoin.

While it= 's pretty far from the original colored coins model, what Flavien have = described is identical to it in majority of aspects.

This is an interesting approach, but OP_RETURN size limitations can be= a significant problem for some kinds of applications.

-----------------------------------------------------------------------= -------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.= sf.net/sfu/13600_Cloudbees
_________________________________________= ______
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e0158aef421664404f6c3ccfb--