There are many open questions now:

1. How do we define a new color, what constitutes a definition?
2. Do we need to embed some meta-information into blockchain itself or side-channel works fine?
3. Do we need to 'tag' colored outputs in blockchain itself or is "order-based coloring" (or some other method) enough?
4. Is it possible to implement efficient 'thin' colored coin client?
5. What if we have more than one "coloring algorithms", how would they interact?

I'm afraid the only way to get definitive question is to implement it and see how it works.

But we are also discussing advantages and drawbacks of different schemes.

I currently see order-based coloring as the best candidate.

There is no formal specification, but it's actually well-documented. (It's just not easy to follow this documentation because it is work in progress.)

Discussion thread: https://bitcointalk.org/index.php?topic=114571.msg1235504#msg1235504

Rules for creation of correctly colored transaction: https://bitcointalk.org/index.php?topic=106449.msg1203918#msg1203918
Rationale for these rules, with examples: https://bitcointalk.org/index.php?topic=106449.msg1169974#msg1169974
Algorithm: https://github.com/killerstorm/colored-coin-tools/blob/master/color.js

(It is JS code, but I believe it isn't any worse description than pseudocode or description with words.)

So this is enough information for someone to comment on this, or to implement it in code.

I'm not claiming that it's 'final' by any means. For example, some people say that order-based coloring enables overlapping colors, and thus tagging is necessary to avoid ambiguity.

A relatively easy approach to handle multiple inputs, and particularly a mix of colored and uncolored inputs, in setting like one used in this script is:

• Get a list of "potentially colored transactions".
• Sort it in such a way that dependencies never appear after dependent transactions. (This is known as 'toposort'.)
• Go through this list of transactions in order and identify all colored outputs. (When we scan transaction we already know which of its inputs are colored and thus it is easy to identify colored outputs.)

This script already has a recursive traversal function (called rec), with some modifications it can be used to identify 'potentially colored transactions'. Moreover, if it produces such list via "reverse postordering", list will be dependency-sorted, see here: http://en.wikipedia.org/wiki/Depth-first_search#Vertex_orderings ("Reverse postordering produces a topological sorting of any directed acyclic graph.")

Then for each transaction, we can count sum of values of colored inputs and use it color an appropriate number of outputs. Additional check should be made to make sure that all colored inputs go before all uncolored.

However, there is a problem: a list of potentially colored transactions might be huge. Especially if you include uncolored outputs.

To solve this performance problem one might limit depth of DFS by block number: i.e. do this coloring process in batches, block by block or something like that. Whenever you see a transaction in a block too far ahead, simple ignore it, it will be considered later. This works because transactions in later blocks cannot affect transactions in earlier blocks.

Well, it is compatible with order-based coloring: if we have one input, it is always in correct order

But I don't think that having two versions (let's call them simple and complex) is a good idea: that would mean that if somebody makes a 'complex' transaction, those coins won't be visible in 'simple' version anymore. Forever: there is no way to repair it for 'simple' version.

Also I think simple version should support at least 1 color + uncolored scheme. This would allow payment of transaction fees, buy/sell atomic transactions etc. There is no need to support more than one color in one transaction, but colored + uncolored is sort of necessary.

Let's clarify the terminology here.

Coin of mixed heritage becomes uncolored. I.e. if you combine 1 red and 1 blue coins into one output, that output is 2 uncolored coins.

Multicolored coin is a coin whose color heritage can be traced down to more than one color definition. I.e. a coin is both a valid red coin and a valid blue coin.

In theory, client can identify that case and show coin as multicolored. But I don't think we are going to implement this anytime soon, let's just say it is a remote, theoretic possibility.


That third place will get two separate coins (formally speaking, transaction outputs). Depending on whether blue definition is enabled it will either show them as, for example, 1 red and 1 blue or as 2 red.

However, if you turn off blue definition and send it to a fourth place, client will naturally melt these two coins into one. A red one.

If you enable blue color in that fourth place, then it will show it as uncolored because it sees red and blue mixed. Shit.

But that's just because we don't have first class support for multicolored coins in our algorithm. It's certainly possible to make an algorithm which would preserve color here (i.e. this mixed output will be recognized as 2 red coins. Basically, "lowest common denominator").

Moreover, there is even a proposal for satoshi-level coloring. In that case even mixing won't destroy any color information.

But I think for the start a simple order-based algorithm will do fine. Just don't make multicolored coins and switch definitions on and off and you will be OK

If there will ever be a need for multi-colored coins, or if it will turn out that mixing is a real problem we can always make a more advanced algorithm which will stay compatible with the old one. (i.e. order-based coloring.)

It's possible to make a p2p solution for laundering where parties would mix their coins via swap transaction. Only your peer will known where your output went.

If considerable number of participants are honest, i,.e. they'll never reveal details of swaps they do, after a large number of rounds coins will be well mixed so it won't be possible to trace inputs to outputs.

E.g. let's say we have 100 honest launderers and 900 FBI agents. After, say, 1000 rounds of coin mixing won't be able to trace particular output to a particular launderer, only to a group of 100 of them.

If a lot of people use this laundry (for example, it might be a feature of their client software: it will perform coin swap transactions even if laundry is not requested, just to protect privacy of others) it would be impractical to use taints, as a huge amount of coins will get "tainted". Thus tainting will neither help you to catch bad guys, nor you can deny receiving tainted coins as you' won't be able to accept coins of honest customers.

So distributed laundry is possible, it can be 100% secure in sense that you cannot lose your money, and it provides reasonable mixing.

The only problem is blockchain bloat, but mixing transactions are prunable, and also it is possible to do aggregation.

So, yes, I think that tainting won't work if enough people will help with laundry...

But, again, this has absolutely nothing to do with colored coins. Can you please move that discussion into some other thread? Thanks.

Color definitions are not exclusive, they can overlap.

Let's say you have 100 black coins. Then you want to buy 1 red coin. But 1 red coin was made out of 1 black coin for some reason.

That is not a problem. If you import red definition and and buy a red coin, your client will tell you that you have 100 black coins and 1 red coin.
The thing is, red color definition affects only coins which were issued through it, and so your black coins will be unaffected.

If red company goes bankrupt, you can erase red definition and then your client will show that you own 101 black coins. Yay!

Perhaps client software should issue a warning when colors overlap, and especially when it affects coins you already own.

If you find some color definition suspicious just don't import it and it will be fine.


The whole point is NOT forcing anybody to do anything. Coloring is essentially a convention, it is very flexible.


Well, client software definitely should protect users from preventable errors. It will choose only uncolored coins whenever you want to issue something.

A special address format will prevent users from sending coins of a wrong color. For example, you want to buy something for 100 "USD coins".
You should first select "USD coins" in currency list, and then you'll enter address merchant have given to you. This address will include information that "USD coins" are requested. Client software will allow you to create transaction only if color definitions match. Otherwise you need to find what's going wrong: perhaps merchant made an error, or he wants a different kind of coins...


Difference between color and taint is that taint is contagious, while color isn't.


It makes absolutely no difference in examples above: even if color is written into blockchain, colors still can overlap, i.e. somebody will recolor some black coins into red coins or something.

It will work exactly the same as with color definitions, but with color definitions you are free to undo that recoloring if you want.


We have considered embedding color meta-information into blockchain.

But it appears that certain protections can be implemented on client-software leel without changing in-blockchain format, and those protections are in fact necessary in any case. So meta-information in blockchain offers very few advantages.

Still, it's not something completely ruled out. For example, tagging with OP_DROP messages might be used... when this txn script will be approved. But it's hard to find benefits.

If anything, tagging in blockchain might make mess with overlapping colors worse because

1. you'll be automatically subscribed to all kinds of bullshit coin issues
2. color tag might be erroneous, then what?
3. you cannot 'undo' color definition

Anyway, the difference between these approaches will be visible only in some obscure corner cases. As long as people simply use client software and do not try to circumvent built-in protection which doesn't allow user to shot himself in the foot they'll be ok.

There were bots on GLBSE (and there are currently bots on currency exchanges).

One basic thing bot can do is market making. E.g. if existing bid is 6 and ask is 7, bot can place a bid at 6.1 and ask at 6.9.

If volatility isn't high, but there is some trading volume, bot can earn some money without a lot of risk.

Essentially risk is limited to bid/ask he puts, but he can buy and sell some amount many times through day.

Also bot can do arbitrage... For example, currently on litecoin global (https://www.litecoinglobal.com/security) there are two bond issues (ESECURITY-SA, ESECURITY-SA2) which have identical condition. Bot could exploit temporary price imbalances, e.g. if ESECURITY-SA is traded below ESECURITY-SA2 bot can sell ESECURITY-SA2 and buy ESECURITY-SA: his net position will be the same, but he earns some money.

By the way:

This isn't a problem because when you issue a new color you essentially redefine meaning of a coin.

It doesn't matter whether coin was previously uncolored, or it was a mix of some colored coins, or it had some color.

Whoever is aware of your color definition will now recognize your coins and will "forget" about previous meaning they had.

For example, if you used a "black" coin output to issue "red" coins, whoever uses your definition will now see it as a red coin, regardless of whether they are aware of "black" coins.

People who are aware only of "black" coins and not "red" ones will effectively see all "red" coins of this issue as "black".

Confusion can happen only in some edge cases, and even then it can be resolved without much effort:

Client software will make sure that you'll get coins only when you know what they are, i.e. to receive red coins you need to import definition of red and ask specifically for red coins. Now somebody owning red coins might deliberately delete "red" definition and client software will revert to previous meaning they had: "black". Now he can sell these coins as black to people who are not aware of "red".

Thus somebody might buy "black" coins which are in fact "red"... But this isn't a problem because:

1. if red coins are more valuable he can simply import definition of red and sell them as red
2. if black coins are valuable he can expect that other people will eventually delete definition of red and will recognize these coins as black

Perhaps there are even uses for this feature... Suppose "black coins" represent shares of a Large Company. This Large Company might want to spin-off one of its divisions. Spin-off's shares will be represented with "red coins" which are made out of "black coins".

In that case spin-off's shares will never be priced below Large Company's shares because they are essentially convertible back to Large Company's shares.

In the same way Large Company can provide guarantees for bonds of its Spin-off..


When coins of different colors are mixed they become uncolored.

Several such projects already exist. They aren't very active, though. I guess the problem lies in trust, or lack of thereof.

Basically, organizer needs to be really serious about it, and he needs to find some serious projects.


This can be done using smart property/colored coins. There is no need for a site as ownership can be securely identified by client software.

A web site could, perhaps, act as a directory, i.e. a place where people can find information on particular property/coins.

I guess the main difference is that we were focusing on allowing to have coins of multiple colors in same transaction, while this version doesn't allow it, comment in code:


More fine-grained color tracking is needed to implement secure exchange: coins of different colors will be exchanged in one atomic transaction.

Otherwise this script seems to be roughly equivalent to the prototype I've implemented about a month ago, in terms of coloring.

That largely depends on issuer's quality standards, i.e. whether he would want to use experimental software with god-awful UI.

Otherwise... I've implemented coloring backend for Armory this week, it just needs a bit polishing. And some wiring to wallets and GUI.

If everything goes fine I'll guess I'll have some proof-of-concept for Armory this week, and maybe some exchange prototype next week.


From what I gather it is an implementation which allows only one color per transaction..  Comment in code:


I had a basic version like this about a month ago, you can find in in form of bitcoind mod here: https://bitcointalk.org/index.php?topic=106373.0

But to implement an exchange we need to include coins of different colors (say, colored and non-colored) in same transaction, so that they can be exchanged atomically.

This is more complex, so it took me a while to design an algorithm which does that and find how to implement it efficiently.

So let's just say I'm not impressed with that guy's work, essentially it is just a commandline interface which looks handy, but technically it is functionally equivalent to a basic prototype I've made a month ago...

mobodick, you forget about merged mining. It doesn't suck hashing power away from it's host chain.

ASICs won't really fundamentally change anything: attackers can get ASICs too, so they will simply make GPU mining obsolete. Just like GPU mining obsoleted CPU mining. Hashing power did not become "abundant" when GPU mining was invented.

It would be definitely more wasteful in the long term.

By the way, I forgot to mention that it is sort of relevant to "colored coins" use case...

Some people are interested in microtransactions, and we have to say that Bitcoin doesn't really support microtransactions due to blockchain bloat problem. (You can certainly send tiny amounts, but txn fees will eat you alive.)

I even asked coblee, Litecoin maintainer, whether they would consider lowering transaction fees to allow microtransactions. He said no, it's not an option right now because they had a problem with uncontrolled blockchain growth due to dust transactions in past.

So I'd say that hypothetical blockchain growth already scares away potential users.

But if we had at least a theoretic solution for blockchain growth  we could tell people that microtransactions are possible, just not implemented right now. That might make a difference.

Also, Meni's proposal of pruning away outputs which are still alive would be a major problem for colored coins/smart property ("oh, you cannot sell you car anymore, it was pruned away, miners won't approve this transfer now"). So I want to find some alternative to it

Yes, I'm aware of general scalability discussions... I wonder if there are schemes which can fundamentally reduce storage requirements, particularly through use of divide and conquer.


Yes, I've read it.

A problem with this article is that it considers scalability from a point of view of a large commercial operator.

But scalability woes can easily prevent end-users from running their own full nodes. Which means that we can end up with just a handful of full nodes which belong to commercial operators. Which are profit-motivated and will run away as soon as costs exceed profits...

This might create security problems. It's much easier to pull off 51% attack if you can disable majority of full nodes via DDoS.

E.g. consider such scenario: there are only 5 mining pools. Operator of 1 mining pool disables 4 other pools via DDoS. Now he can easily do whatever he wants as miners will migrate to his pool.

And p2pool can't help here because very few enthusiasts can afford to run a high-end cluster for a node just for the hell of it.

---

So I think it's important to consider whether solutions to scalability problems, particularly to storage requirements, exist at least theoretically for blockchain-based cryptocurrencies.

If they do not exist, it would make sense to look for alternatives to blockchain. E.g. list of account balances, as described in Ben Laurie's paper.

Pruning is definitely not a fundamental solutions because it's likely that number of unspent transaction outputs would be proportional to number of transactions for quite a while, until we reach saturation.

There are some proposals of more aggressive forms of pruning, where we will cut outputs which still can be spent:
https://bitcointalk.org/index.php?topic=80435.0

This might help, but I wonder whether there is a better way to do this.


It depends how you look at it... Consider somebody running a web store store. A VPS with 1 GB RAM is usually quite adequate to run a web store.

But, for example, a VPS with 1 GB RAM from Linode has only 40 GB of storage. So blockchain might eat a significant portion of it, and thus it would discourage people from running full nodes.


A design sketch I presented above is definitely not much more complex. It is largely theoretical, but I'm fairly sure it can be implemented right now. (I mean, unless there is no major hole in my reasoning.)

Tracking spent transactions in separate chains and linking it from main blockchain is pretty much trivial to implement.

Using this information is also fairly easy and straightforward. It doesn't even require hard fork: nodes who have pruned away too much of their blockchain copy might just start using spent-transaction-chains for verification, and that's all.

Bro, again, this has absolutely NOTHING to do with tainting. You have no idea what you're talking about.

GeistGeld did something similar: http://www.geistgeld.org/about--faq.html

I seriously advice against helping OP. He really doesn't know much on this topic.

It is like "Hey, I have a vague idea, implement it for me and I'll give you maybe 10% of profit." (Spoiler: there won't be any profit.)

While a script which would create merged-mined alt-chains on demand would be cool, it definitely shouldn't be developed under OP's guidance.

By the way, there was a client mod which allowed creation of unlimited number of crypto-currencies: MultiCoin https://bitcointalk.org/index.php?topic=24209.0

But I doubt it supported merged-mining and also it seems to be dead.

Also, um, you say "please invest today" and give your bitcoin address? How is that an investment? Where's contract? Will you pay dividends?

Investing into a can of beer has a better payoff, you know.

Micros, not picos. Or as people already mentioned here "mikes".


I think we all can agree that OP is just somewhat uneducated and stop beating the dead horse.

Also, um, 152×10^-6.

Or, maybe 1.52E-4