Colored coins lecture in Amsterdam conference

[Meni Rosenfeld]

Hi all,

Next week there will be a Bitcoin conference in Amsterdam, and I was invited to give a presentation about Colored Coins. That's definitely something I'm interested in talking about, and having made some contributions to it I find it appropriate that I talk about it, so I'll do it.

Problem is, lately I haven't been involved with Colored Coins as much as I would have liked, so I have some homework to do... And while I planned to do it well in advance, due to other obligations only now I'm starting to work on it. With the Jewish holidays and the preparations for the trip itself, this leaves me with only a few days.

Part of the homework would be to bring my paper https://bitcoil.co.il/BitcoinX.pdf to something other than "work in progress". Hopefully that would mean making it complete, but it will be more realistic to simply remove some unfinished chapters from the ToC.

I have some very rough knowledge of what's been happening lately, but if anyone can give an "executive summary" with some links to information I'll be very grateful. Likewise for any specific ideas regarding the presentation.

As part of the homework I've tried playing around with Webcoinx http://bitcoinx.github.io/webcoinx/, but could not get it to work. I got a testnet coin from the faucet and filled in details in "Issue Coins" tab, but when I click "Issue" nothing seems to happen. Does anyone have an idea what the problem is?

Thanks,
Meni

[Stan Stalnaker]

you can say that Ven is one virtual currency that could and would potentially transact on the colored coins architecture.

Stan Stalnaker: Strategic

+447974156458

London. New York. Bermuda.

HubCulture.com: Humanizing Digital

VEN.VC: Digital money for a better world

--
You received this message because you are subscribed to the Google Groups "Colored coins (BitcoinX)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
To post to this group, send email to bitc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Alex Mizrahi]

Part of the homework would be to bring my paper https://bitcoil.co.il/BitcoinX.pdf to something other than "work in progress". Hopefully that would mean making it complete, but it will be more realistic to simply remove some unfinished chapters from the ToC.

Things got more complicated now, I don't think it's even possible to complete it.

On the other hand, we can use more formalized approach now.

We now think that colored coins is not a concrete technology, but rather a concept (which can be used to build concrete specification/piece of software).

(So there is no such thing as "colored coins specification", but instead we can make "BitcoinX colored coin specification ver. 1.0", for example.)

The basic idea is that we can define color as a function which is applied to each individual transaction in isolation, and if we apply this function to all transactions in a DAG in a certain way, we can get 'color state' of each transaction output.

You can find more information in these discussions in this group:

"the theory of colored coins": https://groups.google.com/forum/?hl=en#!topic/bitcoinX/yxWO4fWHTI8

"advanced color states": https://groups.google.com/forum/?hl=en#!topic/bitcoinX/Tlx12XvgoEs

(first few messages are informative, but then discussion continues at wild tangents).

(Also note that we now differentiate between 'colors' and 'assets': asset can consist of several colors. This solves a number of problems)

On the other hand, compatibility of "coloring schemes" is no longer a big deal, as we understand now that it is possible to create a separate wallet for each incompatible scheme, or even for each asset/color.

Incompatibility between difference schemes can make direct trade impossible, but it isn't a big deal as trade can be done indirectly using Bitcoins as a medium of exchange.

(Perhaps we will iron out incompatibility issues later.)

> As part of the homework I've tried playing around with Webcoinx http://bitcoinx.github.io/webcoinx/, but could not get it to work.

> I got a testnet coin from the faucet and filled in details in "Issue Coins" tab, but when I click "Issue" nothing seems to happen. 

> Does anyone have an idea what the problem is?

This thing is currently under development, might have bugs. I'll try to fix it.

I'll comment on the state of colored coin software a bit later...

[Meni Rosenfeld]

Thanks, will read and look forward for more.

Do I understand correctly that you are using the "BitcoinX" brand for the flavor of colored coins that you are active in developing?

[paul snow]

No, I do not use the BitcoinX brand.   My approach is philosophically very different than BitcoinX.  But you all (and particularly Alex) have been putting way more effort into your work than I have been able to do.  So I am very interested in learning as much as I can from your efforts. 

In particular, I have the following goals:

* Divorce each colored coin from every other colored coin in the system.  Even if you are interested in say five colored coins, the balances of each of those colored coins would be completely independent of any other colored coin.

* Divorce the actual bitcoin balances from colored coin balances.  It is possible to have a transaction that has unspent colored coins, but no unspent bitcoins.

* Processing colored coins in this way does not require any change to the Bitcoin protocol.

* The overhead of managing your colored coin balances is computationally the same as with BitcoinX

* Allow for resetting "on the fly" how much Bitcoin is required to transfer a particular colored coin.  I anticipate the value of Bitcoin rising to much greater values than 130 dollars.  If we are not careful, the bitcoin component could be a higher value than the colored value we are trying to trade.  We have to live between the value of Bitcoin, and the lowest value that the network will allow on a transaction.

The observation at the heart of my approach is that as long as you have an unambiguous method for computing outputs of colored coins for each transaction that involves them, you do not need to try and tie colored coins to actual bitcoins.

On the other hand, Alex seems to reference the discussion with me in his response to you.  I have no problem whatsoever with BitcoinX taking everything from my specification, and I would be happy to refine it with your team if they wanted to.  I guess what I am saying is that what I want to see is a working Colored Coin technology.  I don't have a great deal of ego invested in who gets to build it, or take credit for it.

The specification as it is today for my approach can be found here: http://brownzings.blogspot.com/2013/06/an-alternate-more-simple-implementation.html

--

You received this message because you are subscribed to the Google Groups "Colored coins (BitcoinX)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
To post to this group, send email to bitc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Paul Snow

phone: (512) 627-8841

Fax:    (419) 831-9962 

skype: paulsnx2

[paul snow]

I have been sitting on changes to my specification that I have not published.  I have updated that link.

Enjoy!

http://brownzings.blogspot.com/2013/06/an-alternate-more-simple-implementation.html

Paul

On Sat, Sep 21, 2013 at 12:55 PM, Meni Rosenfeld <meniro...@gmail.com> wrote:

--

[Alex Mizrahi]

Thanks, will read and look forward for more.

Do I understand correctly that you are using the "BitcoinX" brand for the flavor of colored coins that you are active in developing?

Well, not quite...

We still use "BitcoinX" name in some places, but it doesn't mean anything...

(Previously we thought it can be an organization of sorts, but it didn't really work, and I don't like the name enough to keep it.)

I think eventually we'll just make a name for each piece of specification, like "order-based coloring ver. 1.1", "colored asset definition format ver 0.9".

And each piece of software will go under its own name, and will support certain standards.

E.g. "coloredcoinlib supports order-based coloring ver 1.1".

But for now you can simply call it BitcoinX, as it is a name of organization on github where we publish our source code:

https://github.com/bitcoinx/

[Alex Mizrahi]

 

* Divorce each colored coin from every other colored coin in the system.  Even if you are interested in say five colored coins, the balances of each of those colored coins would be completely independent of any other colored coin.

 

It is the case with 'order based coloring' too.

* Divorce the actual bitcoin balances from colored coin balances.  It is possible to have a transaction that has unspent colored coins, but no unspent bitcoins.

 Well, if you do it this way, it shouldn't be called 'colored coins'.

You see, the characteristic feature of a colored coins is that value is associated with transaction outputs (which are colloquially called 'coins', hence the name), and wallet balance corresponds to unspent transaction outputs, just like with normal Bitcoins.

As it is based on the same model as Bitcoin itself, it inherits many characteristics. Particularly, colored coin double-spend is exactly the same as Bitcoin double-spend.

If you no longer associate value with transaction outputs, but instead compute balance for each address, then it is no longer a coin-based system, but rather an account-based.

It is considerably different: now order of transactions in a block becomes important.

Besides that, as we already discussed, in coin-based system you only need a relevant part of a graph to calculate value of a transaction output, but you have to scan the whole blockchain to calculate balance of a certain address in account-based system.

MasterCoin uses this account-based approach, where balances are associated with addresses.

They made it in such a way that it is technically possible to receive and send MasterCoins with an ordinary Bitcoin wallet. 

But in reality people do need special software to check balance and to make proper 'send' transactions, so it is just a gimmick.

I remember you mentioned that you're going to find some way to use Bitcoin graph, but keep features of account-based approach.

I don't know if it is even possible, but why bother?

You will still need special software to send and receive transactions, just like with colored coins.

And just like with normal colored coins, one can lose his coins only if there is a serious bug in software.

I guess you want to explore this alternative approach because you see some problems with normal colored coins. But the thing is, these problems either do not exist, or can be avoid.

For example, we now consider each color in isolation, wallet doesn't need to know any other colors to calculate balance correctly.

Also it's worth noting that we are no longer tied to 'order based coloring'. Theoretic model we are using now allows different schemes to co-exist. Software will have to use separate 'wallets' for schemes which are incompatible with each other.

You can use coloredcoinlib to implement any coloring scheme which follows the general idea of colored coins (i.e. that value is associated with txout and depends only on transaction itself and values of txins). All you need to do is to implement your own ColorDefinition class with run_kernel function, like this:

https://github.com/bitcoinx/coloredcoinlib/blob/master/colordef.py#L24

In case with order based coloring, it is just 25 lines of code.

Then you can use coloredcoinlib to scan the blockchain for colored coins.

[Meni Rosenfeld]

Hi Paul,

Thanks for the input. I agree with Alex that having UTXO correspond to colored coins is a key distinguishing feature of "colored coins"; other approaches may be valid but are beyond my current scope.


I have some followup questions to Alex or anyone else:

1. I didn't find information about the distinction between colors and assets. Did I miss it, or is there a link with more information? Do I understand correctly that an asset is basically a collection of colors? That is, I can issue a "MeniGoldCoin" asset, with a contract that says I will redeem each such coin for 1oz of gold. Then I can associate a color (initial_state + kernel) with this asset, and each coin matching the color commits me to the contract. If I later wish to issue more MeniGoldCoins, I will define a new color and associate it with the same assets. In any case, the wallet software will not by default list the amount owned of each color, but rather of each asset.

Back in the day I raised a security concern - if the private key for a Bitcoin address is stolen, I only lose the bitcoins in that address. But if a private key with issuing rights is stolen, my losses are unbounded as an arbitrary amount of contractually committing assets can be issued. What features do I have to preemptively prevent such a scenario?

2. Regarding the use of separate addresses per color - Is it per color or per asset? Is it still possible to deduce from a colored address the color and the Bitcoin address (which corresponds to the same private key), and vice versa?

If the address is per color, it can safeguard against receiving coins of an asset I want, but of a new color I do not yet recognize. However, this makes the process more complicated, because to receive an asset I need to know which color I am going to receive. What is the solution for this?

3. Do you know of any attempts to implement colored coins other than what Alex is doing and Bits Of Proof? Can you map the key people involved in each project?

4. I understand that NGCCC is currently a python text-interface program. What are its future plans? Will it be built from scratch or will it fork from one of the established Bitcoin clients?

5. Webcoinx is based on Stefan's Bitcoin-js, right?

[paul snow]

On Sun, Sep 22, 2013 at 7:57 AM, Alex Mizrahi <alex.m...@gmail.com> wrote:

 

* Divorce each colored coin from every other colored coin in the system.  Even if you are interested in say five colored coins, the balances of each of those colored coins would be completely independent of any other colored coin.

 

It is the case with 'order based coloring' too.

If someone is holding A B C and D coins and they send me a D coin where I hold D E F and G coins, I am not sure how I validate their sending me a D coin if I don't know about A B and C coins too.  I.e. I don't know how I order coins that I don't know about so that I can validate that they did in fact send me valid D coins.

 

* Divorce the actual bitcoin balances from colored coin balances.  It is possible to have a transaction that has unspent colored coins, but no unspent bitcoins.

 Well, if you do it this way, it shouldn't be called 'colored coins'.

That's fair enough.  Maybe they are Meta Coins?

 

You see, the characteristic feature of a colored coins is that value is associated with transaction outputs (which are colloquially called 'coins', hence the name), and wallet balance corresponds to unspent transaction outputs, just like with normal Bitcoins.

As it is based on the same model as Bitcoin itself, it inherits many characteristics. Particularly, colored coin double-spend is exactly the same as Bitcoin double-spend.

If you no longer associate value with transaction outputs, but instead compute balance for each address, then it is no longer a coin-based system, but rather an account-based.

You know, I started this with a few misconceptions.  Of course, in the process of talking to you and doing the research on the data structures (that I should have done years ago), I quickly came to understand where I had to adjust my (pretty much unnamed) design.  

I am now associating the colored balance with outputs, just like Bitcoin.  I just look for the tags for what colored output is involved.  But outputs that are not tagged leave the colored balance on a transaction with the same validation script, be it a Bitcoin Address or a multi signature.  So there is a bit of extra overhead in tracking unspent coins in my model where there are no Bitcoins left.  

If you go read the updated specification I wrote, and actually addressed the implementation I describe, I think your criticisms would be more helpful to me.

 

It is considerably different: now order of transactions in a block becomes important.

Besides that, as we already discussed, in coin-based system you only need a relevant part of a graph to calculate value of a transaction output, but you have to scan the whole blockchain to calculate balance of a certain address in account-based system.

I need no more of the graph in the blockchain to calculate the colored value of an output than you do.  Likely less (if you allow colored coins to be commingled in a transaction;  sounds like you don't now though.) I do need to know what colored coin is on what outputs in the blockchain, but so do you.   

MasterCoin uses this account-based approach, where balances are associated with addresses.

They made it in such a way that it is technically possible to receive and send MasterCoins with an ordinary Bitcoin wallet.  

But in reality people do need special software to check balance and to make proper 'send' transactions, so it is just a gimmick.

I haven't looked hard at the implementation of MasterCoins.  I should of course.

 

I remember you mentioned that you're going to find some way to use Bitcoin graph, but keep features of account-based approach.

I don't know if it is even possible, but why bother?

You will still need special software to send and receive transactions, just like with colored coins.

And just like with normal colored coins, one can lose his coins only if there is a serious bug in software.

eh...?  Not so much.  Say I want to send you 10 colored coins in my system, and I only have one colored coin.  I send you from the address holding the colored coin  .00100001 bitcoins.  If I have two colored coins, and A has a signature of 11 and B 89, then I send you .0010011 to send you 10 A coins, and .00100089 to send you 10 B coins.

All of us need some special software to compute and verify colored balances.  But my approach isn't so hard. 

I guess you want to explore this alternative approach because you see some problems with normal colored coins. But the thing is, these problems either do not exist, or can be avoid.

For example, we now consider each color in isolation, wallet doesn't need to know any other colors to calculate balance correctly.

Maybe.  I haven't read your documentation;  I have been mostly too busy to even update my own.  I look forward to reading something.

 

Also it's worth noting that we are no longer tied to 'order based coloring'. Theoretic model we are using now allows different schemes to co-exist. Software will have to use separate 'wallets' for schemes which are incompatible with each other.

Do you have any documentation? 

 

You can use coloredcoinlib to implement any coloring scheme which follows the general idea of colored coins (i.e. that value is associated with txout and depends only on transaction itself and values of txins). All you need to do is to implement your own ColorDefinition class with run_kernel function, like this:

https://github.com/bitcoinx/coloredcoinlib/blob/master/colordef.py#L24

In case with order based coloring, it is just 25 lines of code.

Then you can use coloredcoinlib to scan the blockchain for colored coins.

Very good!

Paul

[Alex Mizrahi]

1. I didn't find information about the distinction between colors and assets. Did I miss it, or is there a link with more information?

Sorry, I forgot to include it.

This discussion is called "color definition -> asset definition"

https://groups.google.com/forum/#!topic/bitcoinX/oReAoS0e6Kk

Relevant parts:

We need to revamp color definition infrastructure, largely because there were several problems with additional issues.

Albert gave us a great idea: separate notions of color and asset. Color exists in context of coloring algorithms, asset is a meaning we associate with a set of colors.

Transaction outputs are of color X if they can be traced back without mixing to a genesis of color X which is a single transaction output. 

Making "one color = one genesis TXO" a rule simplifies things.

 

Conclusions are based on analysis:

issuing more coins of a same asset [1/4]

https://groups.google.com/forum/#!topic/bitcoinX/30rx0-XHI5E

Re: issuing more coins of a same asset [2/4]

https://groups.google.com/forum/#!topic/bitcoinX/CQd8ceEuUk4

(There are no parts 3 and 4.)

Do I understand correctly that an asset is basically a collection of colors?

Yes.

 

That is, I can issue a "MeniGoldCoin" asset, with a contract that says I will redeem each such coin for 1oz of gold. Then I can associate a color (initial_state + kernel) with this asset, and each coin matching the color commits me to the contract. If I later wish to issue more MeniGoldCoins, I will define a new color and associate it with the same assets.

Yes, you create a new 'asset definition' each time you issue another color, but they all reference same contract.

 

In any case, the wallet software will not by default list the amount owned of each color, but rather of each asset.

Yes. 

Back in the day I raised a security concern - if the private key for a Bitcoin address is stolen, I only lose the bitcoins in that address. But if a private key with issuing rights is stolen, my losses are unbounded as an arbitrary amount of contractually committing assets can be issued.

I'm concerned with such a scenario too, this is why I ditched "issuing address" approach: client should never just trust issues automatically, it should be a configurable policy, with a possibility of manual override.

 

What features do I have to preemptively prevent such a scenario?

There are two related issues here:

1.  investors should be protected from buying 'fake' assets (i.e. not properly authorized by the issuer)

2. issuer should have protection from claims to redeem non-authorized assets

The second problem lies in legal realm; I'm not an expert here, but I guess you can add a clause to contract that additional issues are valid only if it confirmed through a certain process.

The simplest confirmation is to require signatures of several trusted parties (as it is unlikely that all of them will be stolen), and this kind of confirmation can be verified automatically (i.e. asset definition has a list of public keys of parties signatures of which are required to update this asset).

But if you do not want to rely solely on digital signatures, you can require more complex confirmation process, even something which cannot be done automatically. E.g. issuance is authorized if signature is valid AND issuer haven't recalled it within one week. As it is a legal document, it can be anything court can verify, (and what investors can potentially verify).

Now as for protection for investors, we want to spare them of the effort to verify all the things.

So we can introduce a notion of Color Rating Agency.

Client will check for asset definition updates from a list of CRAs investor trusts.

Asset definition will be updated only if it is signed both by issuer and by CRA.

CRA is supposed to verify validity of asset definitions, adherence to contracts, etc.

Are you familiar with approval and moderation process on btct.co?

I think CRAs can work in a same way, so it will be same for investors and issuers, except that trading platform isn't proprietary and there is an easy escape path in case CRA goes bad.

So, all in all, it can work similarly to existing Bitcoin stock exchanges, or better :)

2. Regarding the use of separate addresses per color - Is it per color or per asset?

Per color set: you need a new address when you update asset definition.

All colors within one asset are supposed to be compatible with each other, i.e. it is possible to send them all within one transaction.

 

Is it still possible to deduce from a colored address the color and the Bitcoin address (which corresponds to the same private key), and vice versa?

Not specific color, but a set of accepted colors.

 

If the address is per color, it can safeguard against receiving coins of an asset I want, but of a new color I do not yet recognize.

Yes.

 

However, this makes the process more complicated, because to receive an asset I need to know which color I am going to receive. What is the solution for this?

Address includes color_set_hash, which acts as a proof that receiving party recognized a certain set of colors as fungible.

 

3. Do you know of any attempts to implement colored coins other than what Alex is doing and Bits Of Proof?

There was also bitpaint.py, but last release was 10 months ago, I think.

Also perhaps it's worth noting that Freimarkets are similar to colored coins, but this requires protocol update, and they are on the design phase now, I think.

 

Can you map the key people involved in each project?

There are several people who contribute code to "ex-BitcoinX" projects, but only I'm working on design and architecture now.

 

4. I understand that NGCCC is currently a python text-interface program. What are its future plans? Will it be built from scratch or will it fork from one of the established Bitcoin clients?

The core of NGCCC is coloredcoinlib, which is a Python library which can be used to compute color value of transaction outputs. It uses pycoin by Richard Kiss for transaction signing.

Currently the plan is to improve what we have now, as with a client which is implemented from scratch we can do things in simplest and most straightforward way, so we can be sure that it works correctly.

Adding functionality to an established Bitcoin  client requires more manpower, which we lack now.

There was a plan to make a colored coin Electrum mod. While it won't be a problem to use Electrum's internals, using its user interface requires considerable efforts.

 

There was also a plan to make a C++ port of coloredcoinlib. I offered 7 BTC bounty for it, but person who accepted this offer didn't release anything so far, and I doubt he will.

5. Webcoinx is based on Stefan's Bitcoin-js, right?

Yes. Front-end is based on bitcoinjs-gui and bitcoinjs-lib.

It now uses bitcoinjs-server as a backend, but the plan is to ditch it and use electrum-server instead. bitcoinjs-server has too many problems.

Actually, bitcoinjs-gui and bitcoinjs-lib have lots of problems too, but there are no better options...

[Alex Mizrahi]

If someone is holding A B C and D coins and they send me a D coin where I hold D E F and G coins, I am not sure how I validate their sending me a D coin if I don't know about A B and C coins too.  I.e. I don't know how I order coins that I don't know about so that I can validate that they did in fact send me valid D coins.

"Order-based coloring" doesn't mean that colors need to be order in some particular way. 

It means that order of inputs and outputs within transaction is important and is used to determine which outputs match which inputs.

E.g. suppose a transaction has three inputs, 1 BTC each. And three outputs, 1 BTC each.

Then first input matches first output, second input matches second output and so on.

There is a simple algorithm which can tell what matches what in a general case.

It is easy to visualize it: 

Suppose you stack inputs on top of each other, with height being proportional to their value.

Then stack outputs in same way.

http://i.imgur.com/UIFfvr8.png

Each output will intersect with inputs it matches.

E.g. first (from top) blue output matches first two inputs.
Second output matches only second input, as it doesn't intersect with the first one.

Same thing with pink outputs.

So when client makes a transaction, it only needs to make it so that outputs of one color are matched by inputs of same color (which means that they don't intersect with inputs of a different color).

Now suppose client have received a transaction output and it doesn't know its color. It can check whether it is of color D using a recursive backward scan procedure:

1. it finds inputs matching to output in question

2. then finds outputs which these inputs spend

3. then finds inputs matching those outputs, and so on.

If output is of color D, then client will eventually reach output which is genesis of color D.

If it reaches coinbase transaction, then output in question is not of color D.

Of course, it is possible to check many colors at once using this recursive scan procedure, and result will be exactly the same as checking each color individually.

Hence it is not necessary to know all colors.

Note that we can get into a situation where output is colored both as A and B.

It can happen only if genesis of A is of color B, or genesis of B is of color A.

[Meni Rosenfeld]

2. Address per color set is an elegant solution.

When you say "All colors within one asset are supposed to be compatible with each other, i.e. it is possible to send them all within one transaction.", do you mean to combine them into a single output, or having separate outputs per color, but to the same address? The former has serious security implications as you describe in part 1/4.

--
You received this message because you are subscribed to a topic in the Google Groups "Colored coins (BitcoinX)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoinX/RG0F-EoT67o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoinX+u...@googlegroups.com.

[Alex Mizrahi]

When you say "All colors within one asset are supposed to be compatible with each other, i.e. it is possible to send them all within one transaction.", do you mean to combine them into a single output, or having separate outputs per color, but to the same address? The former has serious security implications as you describe in part 1/4.

Yes, separate output for each color.

I meant that it's better when all colors within an asset use same coloring kernel, although it isn't a strict requirement.

[Alex Mizrahi]

As part of the homework I've tried playing around with Webcoinx http://bitcoinx.github.io/webcoinx/, but could not get it to work. I got a testnet coin from the faucet and filled in details in "Issue Coins" tab, but when I click "Issue" nothing seems to happen. Does anyone have an idea what the problem is?

I've updated it to a new version. Seems to work now, but it's a development snapshot, so do not expect much...

Particularly, it fails to initialize properly when you launch it for the first time, so reload page if you see an empty receive tab.

Also there are several known problems with p2ptrade.

[Meni Rosenfeld]

Cool, I managed to issue, can't do any p2ptrade though.


One other thing... Are there any new ideas for applications of advanced color states and kernels? TaxedCoin, referral programs and KYC compliance aren't very sexy and I don't want to include them.

[Alex Mizrahi]

Cool, I managed to issue, can't do any p2ptrade though.

Ouch, it looks like I've killed it with in a  recent update. 

One other thing... Are there any new ideas for applications of advanced color states and kernels? TaxedCoin, referral programs and KYC compliance aren't very sexy and I don't want to include them.

Sadly, usefulness is limited due to inability to use external data. Perhaps this requirement can be relaxed. Or maybe there is a trick which would allow to use external data (i.e. it needs to be encapsulated and delivered locally).

However, there are several interesting applications which do not need external data.

One of them is fully decentralized prediction market.

Usually prediction markets need some kind of authority to perform the settlement: authority tells whether outcome of event is positive or negative, and there is no way to override its decision.

This rises concerns: what if authority is dishonest? What if it will be hijacked?

Also centralized prediction markets usually do not allow controversial bets, e.g. on assassinations. (Because of this: http://en.wikipedia.org/wiki/Assassination_market )

What if we replace centralized authority with decentralized consensus?

This would be interesting, but there is a flaw: suppose 80% of investors bet on YES, but outcome was NO. Now it makes sense for them to collude and to claim that outcome was YES to avoid losses.

So "consensus market" is different from prediction market, as there is no strong link to real-world events.

However, with advanced color states we can make coins non-fungible. Previous settlements can be recorded in the state of the coin. 

The crux of the matter:

Market participants can examine states of coins and reject ones which have wrong settlements in their history.

Let's consider same situation: 80% of market participants bet on YES, but NO won.

Suppose that 80% will record YES in the settlement history of their coins, while 20% will record NO.

This would create a schism: NO-group will refuse to accept coins of the YES-group as valid.

However, members of the first group can continue to use them among themselves.

However, this market doesn't exist in isolation, people would want to exchange their prediction market coins into Bitcoins, and vice versa.

We can expect that new participants will have a strong preference for NO-group coins as there are only honest settlements in its history. YES-group coins will be seen as defective. 

So we can expect that YES-group coins will eventually be nearly worthless.

This creates a strong incentive to avoid collusion. 

It is possible to design this system in such a way that person gets 10% of his bet back even if he bets on the wrong outcome, and it is better to get 10% back than to make your coin worthless via invalid settlement.

So I expect that if majority of participants are rational and everybody understands rules of the game (i.e. preference for coins which have only honest settlements in their history is a focal point of sorts), majority will insist on honest settlements, which makes this system sound.

I won't describe exact protocol here, as it is kinda complex (complex compared to other things we do with colored coins, but not complex in the grand scheme of things), but I believe it is doable, and I currently see no flaws in this.

It is also possible to implement a prediction market which would rely on a central authority for settlements. Such an implementation will likely be simpler and not as controversial.

But fundamentally all cryptocurrencies rely on consensus among participants, so it is fundamentally possible to rebel against authority which produced erroneous settlements (or refuses to produce settlement when it is required). I.e. it is possible to switch to a different authority when needed.

Colored coins can provide a comfortable means for such a rebellion: it will be a process with well-understood model, and can be accomplished using a simple software update.

(It will be similar to Bitcoin hardfork: maybe not exactly smooth, but doable.)

I  believe it is possible to apply same ideas to derivative markets, i.e. provide a means to settle financial bets according to consensus, with no reliance on central authority, or with minimal reliance.

I haven't done any research on it yet, but in general it seems to be similar to prediction markets.

[Alex Mizrahi]

I already described possible ways to implement derivatives, such as CFDs and futures, using colored coins.

But they were bond-like, i.e.:

 * settlement was done in Bitcoins, and it had to be done by issuer, according to contract

 * colored coins are used only to represent ownership of contracts, they have no inherent value

 * there is a counter-party risk: if issuer loses Bitcoins he holds, derivatives are worthless as there will be no settlement

This is what we could do with simple colored coins.

But advanced kernels/color states allow us to do it in a different way: we can create a new currency which will be used for settlements. Units of that currency can be transformed into derivative contracts and back to units of currency.

It will still rely on a centralized authority to perform settlement, although there is also a potential fully decentralized solution.

Counter-party risk is drastically reduced as operator doesn't need to hold Bitcoins.

Here's the general idea:

 * initially coins are in state of currency, they are fungible

 * user can transform his coin into a derivative, to do that he makes a transaction with extra piece of data which describes properties of derivative according to certain language which is recognized by this color

 * derivative-coin can still be transferred, but it is not fungible, it cannot be mixed with other coins, and other users won't confuse it for a unit of currency

 * settlement is done using a special transaction. there are two options:

 * * transaction requires a signature of central authority; authority will make sure that settlement is valid, i.e. it pays correct amount of currency to user, and derivative-coin no longer exists

 * * two sides of a same derivative, i.e. long and short position, will cancel each other; in this case no intervention of authority is required, as correctness of such transaction is unconditional; sides need to agree on amount of currency they get, but total amount cannot exceed the amount which was used to create derivatives

This rules will make sure that conservation rules are met, so we'll have a currency with limited monetary base.

[Alex Mizrahi]

Cool, I managed to issue, can't do any p2ptrade though.

I've fixed the problem, it's now possible to trade.

But there are still several issues with it:

 * it might take some time (several rounds) due to race conditions

 * only integer quantity works, and also price is actually cost...

 * so it works correctly is quantity=1