From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WYIiF-0006nC-95 for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 17:24:31 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.181 as permitted sender) client-ip=209.85.216.181; envelope-from=alex.mizrahi@gmail.com; helo=mail-qc0-f181.google.com; Received: from mail-qc0-f181.google.com ([209.85.216.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WYIiE-0008Jd-Gc for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 17:24:31 +0000 Received: by mail-qc0-f181.google.com with SMTP id x3so4754587qcv.12 for ; Thu, 10 Apr 2014 10:24:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.88.131 with SMTP id a3mr22271962qam.54.1397150664936; Thu, 10 Apr 2014 10:24:24 -0700 (PDT) Received: by 10.96.77.38 with HTTP; Thu, 10 Apr 2014 10:24:24 -0700 (PDT) In-Reply-To: <5346CDD4.8050206@monetize.io> References: <5341E1FF.7080204@monetize.io> <5342BEE0.3050204@monetize.io> <5346CDD4.8050206@monetize.io> Date: Thu, 10 Apr 2014 20:24:24 +0300 Message-ID: From: Alex Mizrahi To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c2dac014d1ab04f6b37d67 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (alex.mizrahi[at]gmail.com) -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: 1WYIiE-0008Jd-Gc 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: Thu, 10 Apr 2014 17:24:31 -0000 --001a11c2dac014d1ab04f6b37d67 Content-Type: text/plain; charset=ISO-8859-1 > 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. --001a11c2dac014d1ab04f6b37d67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=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 differenc= e between colored coin model and Mastercoin model is that colored coins are= linked to transaction outputs, while Mastercoin has a notion of address ba= lances.

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.
--001a11c2dac014d1ab04f6b37d67--