public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Flavien Charlon <flavien.charlon@coinprism.com>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Feedback request: colored coins protocol
Date: Fri, 11 Apr 2014 13:51:10 +0100	[thread overview]
Message-ID: <CABbpET_bP5tgXBzOCoEaO3iQof4A5tFF1-BxO4JYHrvKN-TU_A@mail.gmail.com> (raw)
In-Reply-To: <CAE28kUSWwamovgPA1AvAojoKuwaDvuWzbnYf6yJhQ89HRnOJGg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

I have updated the
spec<https://github.com/Flavien/colored-coins-protocol/blob/master/specification.mediawiki>
.

> 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<http://en.wikipedia.org/wiki/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 <alex.mizrahi@gmail.com>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
>
>

[-- Attachment #2: Type: text/html, Size: 3412 bytes --]

  reply	other threads:[~2014-04-11 13:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-06 20:59 [Bitcoin-development] Feedback request: colored coins protocol Flavien Charlon
2014-04-06 23:23 ` Mark Friedenbach
2014-04-07  9:49   ` Flavien Charlon
2014-04-07 12:12     ` Jorge Timón
2014-04-07 14:00       ` Flavien Charlon
2014-04-07 15:06         ` Mark Friedenbach
2014-04-07 15:19           ` Flavien Charlon
2014-04-07 18:23             ` Jorge Timón
2014-04-07 19:26               ` Flavien Charlon
2014-04-07 19:58                 ` Alex Mizrahi
2014-04-10 12:19                   ` Flavien Charlon
2014-04-10 14:28                     ` Jean-Pierre Rupp
2014-04-10 16:59                     ` Mark Friedenbach
2014-04-10 17:24                       ` Alex Mizrahi
2014-04-11 12:51                         ` Flavien Charlon [this message]
2014-04-07 11:28   ` Alex Mizrahi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABbpET_bP5tgXBzOCoEaO3iQof4A5tFF1-BxO4JYHrvKN-TU_A@mail.gmail.com \
    --to=flavien.charlon@coinprism.com \
    --cc=alex.mizrahi@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox