Bitcoin Forum

Overview of 'colored bitcoin' concept and useful links are here: https://bitcointalk.org/index.php?topic=106373.0

We introduce certain "color" of bitcoin (i.e. a label) by associating it with a certain transaction (or transaction output). I.e. transaction with hash X would be a genesis transaction for color Y. I assume that this information will be present in configuration files of client software in case use is interested in distinguishing color Y.

Then to check whether a transaction or transaction output is of color Y we need to find whether we can trace it back to the genesis transaction.

Coloring whole transactions is easy: transaction is of color Y if all of its inputs come from transactions of color Y. (With exception of genesis transaction.)

(Coins of color Y will turn into ordinary, uncolored bitcoins if they are mixed with anything but color Y. So essentially these coins are 'lost' w.r.t coloring.)

I've already implemented a proof of concept which implements this very simply coloring scheme. But it's not cool.

One thing, we do not want to pay transaction fees with colored bitcoins, so we need to allow mixing colored and noncolored bitcoins within one transaction. Simplest solution is to assume that all non-colored ones are spent as a fee and amount of colored ones is preserved.

But to make a decentralized exchange based on colored bitcoins we need to be able to have coins of different colors within one transaction without mixing them. I.e. we need an unambiguous coloring scheme which would preserve amounts of colored coins.

This is an open question. I have a number of ideas, though.

Interesting :)  If you don't like the blue ones send them my way.  Another possible metric of interest would be date of birth. 

If I have 1 bitcoin that was entirely created on Jan 25, 2009, it's DOB would be Jan 25, 2009.

More common of course would be that fractions of my coin are from different coinbase transactions.  In that case you would do a weighted average of each of the days involved, weighted by amount of coin.   

Some interesting statistics could develop from this analysis, such as DOB variance of transacted coins, etc. 

This kind of thing is interesting and could be useful but of course in the end one old blue coin is worth the same as a young red one. 

Are you joking, or your seriously do not understand the concept? (I hope you've read message I've referenced.)

Here's an example:

Let's say I'm an owner of a company XYZ and I want to sell its shares. I can sell those shares on GLBSE, then ownership of company is represented by some records in GLBSE's database. In this case I declare that whatever information GLBSE stores is legit.

OR I can declare that legal owners of company are ones who own bitcoins which can be traced to a 1 BTC transaction I've made, and each mBTC one owns represents a share equal to 1/1000 of a company.

Then I'll sell mBTCs derived from that transaction for a price way above 1 mBTC.

So, well, what's the difference between first approach and second approach? In second case we have company ownership which is totally transparent, secure and verifiable.

In same way one can introduce a private currency, i.e. one which is pegged to USD, for example. (It can work like Liberty Reserve, but better.)

Ah, no I hadn't understood.  Thanks.

That's a good idea.  I'll try to reiterate to see if I got it right. 

I could say that one bitcoin, history unimportant, represents interest in my private business venture.  One could then send out .01 from this input to different outputs for each of 100 shareholders.  Shareholders can verify their shares are legit by showing they own a piece of coin tracing back to this original coin. 

Nice idea, kind of like marked bills but with the advantages of bitcoin.  Just don't forget and go spend it at satoshi dice :) 

Right. The client mod I'm developing would kinda 'lock' colored coins one owns making them unavailable for spending. To spend them one needs to switch to that color. But if company goes bankrupt, sending those coins to satoshi dice might be a right choice :)

I've identified following general approaches which can be used for coloring of transaction outputs:

1. Based on law of conservation, i.e. color mapping is valid when it preserves amounts of coins participating in transaction.
2. Based on ordering, i.e. color depends on ordering of outputs within a transaction.
3. Based on meta-info included in transaction. Say, colored outputs might have special meta-info embedded in script (e.g. OP_DROP message).

Law of conservation can work in some cases, e.g. if input is 3 red and 7 blue coins, and outputs are 7 X and 3 Y, then X = blue and Y = red.
However, there is potential ambiguity: if we have 5 red and 5 blue, we won't know how to color outputs.
Also, coloring might require exponential time.

There are possible workarounds, but I think none of them are practical except a combination of conservation law with ordering. (See below.)

Inclusion of meta-info obviously solves all ambiguities, but it might be problematic to implement and it adds bloat to the blockchain.

So here's how ordering-based approach can work. Basic idea is that we know order of colors in inputs, and we assume that outputs go in same order. (I.e. client software must create transactions involving colored bitcoins in this way). Let's start with a simple example:

Inputs: [1 red, 1 blue, 1 green]
Outputs: [1 X, 1 Y, 1 Z].

Obviously, X = red, Y = blue, Z = green.

Now a bit more complex example, where number of inputs and outputs do not match:

Inputs: [1 red, 1 red, 1 blue, 1 green]
Outputs: [2 X, 1 Y, 1 Z]

Again fairly obvious, two red inputs will be grouped together. Same works with situation reversed:

Inputs: [2 red, 1 blue, 1 green]
Outputs: [1 X, 1 Y, 1 Z, 1 W]

Inputs define ordering R->G->B. First output must be R, but we have 1 red coin left. So second output is red too, and the rest is trivial.

At this point we see a general algorithm: first go through inputs to find order of colors and compute total amount for each color.

Then we go through outputs in order having two state variables: current color and amount of coins of this color left. For each output we declare that it is of 'current color' and reduce amount of coins left by that output's amount. When amount goes to zero we go to next color. If we ever have negative amount, coloring is erroneous and we assume that all outputs are uncolored. (I.e. owner does not care about colors anymore.)

Fairly simple.

What's about uncolored coins? We want to pay fees with uncolored coins. To do that, we should include them in the end of transaction.

In case fee is paid, we will end up with positive amount left in the end, but this is not a problem because we have no more outputs to color and it won't confuse our algorithm. (Also, one can pay a fee with a colored coin: that color should just come last.)

Example:

Inputs: [1 red, 1 blue, 1 uncolored]
Outputs: [1 red, 1 blue, 0.95 uncolored]

Finally, suppose that we don't know about certain colors, i.e. we see those colors as uncolored. Is that a problem? No. Example:

Inputs: [1 uncolored, 1 uncolored, 1 red]
Outputs: [1 X, 1 Y, 1 Z]

X and Y will be uncolored, Z is red. We don't know whether X and Y are of same color or not, but we only care about red, and we can figure out red.

Note, however, that if client received coins of colors he is not aware of, he can get them all mixed up and thus spoiled. But then it's his own problem since he only removes potential value from himself.

I've found a couple of corner cases which make this rule problematic:


For example, suppose person only knows (and cares) about red coins, but he accidentally receives blue and green coins. (I.e. other clients are aware of this colors. Maybe they are not valuable.)

This person's client might construct a transaction like this (his client software thinks that green and blue are uncolored, so they go in the end):

Inputs: [1 red, 1 green, 1 blue]
Outputs: [1 X, 2 Y]

If clients who are aware of green and blue will simply find whole transaction erroneous and assume that all outputs are uncolored, person will lose red coins.

To avoid this unpleasant situation, we should replace it with a following rule:


With this rule, person can only accidentally uncolor coins he thought are uncolored anyway, but he will never lose coins which he thinks are colored because they go before all uncolored coins.

Note that more complex rule which preserves as much colored coins as possible can be constructed, but I'm not sure it's necessary. Basically, we need to recover from erroneous situation. E.g.

Inputs: [1 red, 1 green, 3 blue]
Outputs: [1 red, 2 X, 2 Y]

X will be uncolored since coins are mixed, but Y will be blue.

Change to rule is rather simple: if we encounter a negative amount, we switch to next color and increase amount left by this color's amount. We will mark only output which brought amount to negative as uncolored, i.e. only an output which spans several colors.

Another corner case is client unaware of green and blue coins creating a txn with non-adjacent colors, e.g.:

Inputs: [1 red, 1 green, 1 blue, 1 green]
Outputs [1 X, 1 Y, 1 Z, 1 W]

In this case simplest resolution is to assume that inputs are uncolored from the point where we've got a duplicated color. So in this example W is uncolored.

Again, there is an alternative rule which would preserve as much colors as possible (it will sum up only adjacent colors), but I'm not sure it's necessary since clearly such transactions are a result of misunderstanding.

Now I think all possible cases are covered.

I played around with the necessary rule sets to deduce the output color from the inputs colors.

A transaction conforming to colored bitcoins has to meet the following requirements:
1) always list colored inputs and outputs before any uncolored inputs and outputs
2) inputs with the same color have to be consecutive
3) the order of the color has to be the same in inputs and outputs
4) the coin value per color has to be preserved (same in input and output)
5) any mining fee has to be paid from uncolored bitcoins, which are listed last

If a transaction follows these conventions then the client can perform -what I call - "incomplete color validation":
A client will be able to correctly calculate the color of outputs, independent of the degree of color knowledge and the position of the color.

If a transaction does not meet these requirements it makes it generally impossible to correctly compute the output color assignment. (there are some exceptions).

I created some proof-of-concept code as a python script: (validate.py)
http://ubuntuone.com/2XbRs0kFL8A2v65QCq4KLY (http://ubuntuone.com/2XbRs0kFL8A2v65QCq4KLY)

and some artificial input transactions: (transactions.yaml)
http://ubuntuone.com/0nGM4g7uGDbkdhY2LAnkrQ (http://ubuntuone.com/0nGM4g7uGDbkdhY2LAnkrQ)

command line: python validate.py transactions.yaml

The code contains a validate function which is able to compute the output colors by exploiting the above rules.
The script also does some random color deletions which I used to test the stability of the procedure to a varying degree of color information.

So far it looks good. I guess we can settle on the above rule set and focus on tracing colors through the block chain.

I call black. sorry, black is already taken- please choose a new coin color

JFYI, copying from another thread (https://bitcointalk.org/index.php?topic=106373.msg1225948#msg1225948) so everyone stays on the same page...

pybond (https://github.com/jgarzik/pybond) will also be a colored coin implementation, with a subset of colored coins being distributed bonds.  Have a lot of networking boilerplate to write first; the basic design is simply following "rules for colored coins" and "atomic coin swapping" though.

P.S. My name for colored coins is "smartcoins."  Sexier, more marketing friendly name ;p

Other thread references:

Rules for colored coins - https://bitcointalk.org/index.php?topic=106449.msg1203918#msg1203918
Smart property - https://bitcointalk.org/index.php?topic=41550.0
Distributed bonds - https://bitcointalk.org/index.php?topic=92421.0
Atomic coin swapping - https://bitcointalk.org/index.php?topic=112007.0

On the wiki:

https://en.bitcoin.it/wiki/Smart_Property
https://en.bitcoin.it/wiki/Contracts

I'm still not getting how this is better than an alt-chain with merged mining (like namecoin)? I'm admittedly not an expert on how the blockchain, alt-chains, and merged mining work; but that approach sounds more flexible and with fewer possibilities of screwing up the bitcoin blockchain. It also doesn't need all the bitcoin clients to be changed to account for handling colored coins.

Also, what if you want more colored coins than can be derived from one origin block? That is, how do you make more than 50btc worth of one color?

The benefit is that you use existing infrastructure to implement higher order functionality. The cryptocurrency provides network security and irreversibility, while a protocol on top of bitcoin implements contract or assignment logic.
It's like TCP and HTTP. TCP takes care of the network and handles the communication on the IP layer, while HTTP takes care of creating content which can be displayed...

There are some ideas floating around on how to create either inflatable or non-inflatable "colors". Since the color protocol definition (or smart coin, or whatever you want to call it) is just meta-information, it basically depends on convention. E.g. if color is associated with all outputs which come from a specific BTC address you have an inflatable color. If color is associated with a specific output in a transaction incorporated into the blockchain at some point, you have a non-inflatable color.

It's thus knowledge build into the client software... not into bitcoin!

ADDENDUM: I should add that the concept of coloring is universal to cryptocurrency. Thus color could be denoted in BTC, LTC, PPC or whatever your favorite is... (however it is scoped to the particular blockchain)

"tinted coins"?

"tainted coins" is most accurate... if right out.

This would allow one to create a private currency/asset token with a few clicks in client software. Once you've issued these 'colored coin' tokens no maintenance is necessary.

There is no reason why we cannot carry millions or even billions of different kinds of tokens within one blockchain. When people do not transact, there is no information being sent or processed.

Merged mining is a different beast, there is a lot of friction.


On the contrary: colored bicoins are bitcoins, transactions with them are indistinguishable from normal bitcoin transactions. There is no way it can screw the bitcoin blockchain.

OTOH merged mining has to embed its meta-info into blocks... It's literally about screwing with blockchain.

Also I'd say colored coins are more flexible... Although that depends on how you define flexibility.


We do not need to change all clients. If you care about colored coins you need a special client which recognizes them. Otherwise you would see them as normal bitcoins.


They are not derived from a block, they are derived from genesis transactions. Basically, you just need to notify people that coins you currently have are of a certain color.

Tainted coins is a different thing. Taint is supposed to be contagious: if tainted coin is mixed with non-tainted, the result is tainted.

If colored coin is mixed with uncolored, the result is uncolored.

I agree that "smartcoins" sounds much better, but term "colored coins" sort of makes sense during development: we can talk about coin's color, coloring algorithms etc. Term "color" isn't used for anything else, as far as I can tell, so it is unambiguous.

Let's go back to discussion of coloring algorithms... Jutarul's implementation does not cover case I mentioned in second message, i.e. when sender has partial information, but receiver who does validation has complete. In that case validation fails, so sender loses coins he had even though they were used correctly.

I've implemented an algorithm which is both simpler and covers all cases I can imagine: it colors all coins which can be reliably colored, marking the rest as "uncolored".

Here's C++ proof-of-concept implementation: https://gist.github.com/3793725

Run an example embedded in code:


Run with your own inputs/outputs:

Sample colors.txt is included.

Now a bit of discussion:
We assume that colors of inputs and colors of outputs go in same order.
Algorithm tries to recover from situations with partial information as much as possible without backtracking.

The reason we do not do backtracking is that it is computationally expensive and totally unnecessary.
The reason we don't do it in a more strict way is that
1) there is no way partially recovery might hurt one; conservation rule isn't violated;
2) it might save somebody's ass, though
3) extra checks are unnecessary.

So we go through inputs and outputs in order, matching them.
We go through outputs one by one to find their colors.
While we do that, we go through inputs to match amounts of outputs, essentially eating enough inputs to cover sum of outputs so far.
We track color of inputs we have eaten. If we need  inputs of different colors to match ouput, that output gets assigned mixed" color, which is semantically same as uncolored.

Here is pseudo-code derived from actual C++ code, it lacks type information and has extra comments: https://gist.github.com/3793879

A viable alternative to order-based coloring is embedding meta-info into a scriptPubKey.
The most straightforward way to do this is OP_DROP message, but there is a rather elegant approach which uses already standard multisig transactions:

For each color issuer will create a keypair, and BOTH private and public key will be revealed in color definition.

Transactions with this color should have scriptPubKey which is 2-of-2 multisig with first pubkeyhash being pubkeyhash of color's keypair.

Thus to spend a colored coin one needs to sign transaction using color's private key.

Thus it is only possible to spend a colored coin when you've got its definition which includes private key.

This effectively prevents accidents when user would receive a colored coin by a color-unaware client, or before color definition is loaded. User won't be able to use (or even see?) this coin until he uses software which can handle it.

I think it's a cool feature, but still order-based weak coloring algorithm (OBWC) is superior because it doesn't limit what scriptPubKey one can use, so it's compatible with pretty much everything imaginable.

So I think it's better to use OBWC as a base and use multisig color tagging (MCT) as an additional safety measure.

There are, however, different opinions. Jutarul proposed to use color tagging without OBWC. I guess he'll tell us his part of the story...

Anyway, it looks like having multiple coloring algos would be a major PITA (I can show an example if somebody wants), so it's important to settle on some base algo. For example, we can adopt OBWC, all alternatives should be OBWC-compatible.

When colored coins come up I always hear the example of shares / stock. But when it comes to securities, determining ownership and decentralizing the exchange is simply not an interesting problem, compared to the bigger problem of ensuring that the issuing company is trustworthy (which is more of a social problem rather than a technological one).

Not sure "screwing with the blockchain" is accurate or fair.

Merged mining is preferable to colored coins, because you do not bloat the blockchain with person-to-person property transfers.

However, colored coins offer the unique advantage of being automatically swapped for bitcoin payment.

It is a trade-off.  Merged mining is far more scalable, and many discussions about creating a "data chain" for timestamping have been discussed.

No, that is the opposite of elegant:  it adds blockchain bloat that is difficult to recognize or avoid or prune.

I believe there is a demand for a secure trading platform which doesn't try to be an investment bank.

You probably know that Goat was delisted from GLBSE. Maybe he shouldn't have been there in the first place, but now this delisting creates problem for Goat and for people who bought something from him.

Or imagine a situation where GLBSE will suffer from catastrophic data failure, it it will be hacked. Do people have a backup plan?

Suppose they even have a list of owners (this features is offered by MPex), can they continue trading after being delisted or after some problem with exchange?

With a trading platform based on colored coins ownership data is encoded in a blockchain, it cannot be lost, it cannot be hacked in realistic scenarios. You cannot be delisted. You will be able to trade no matter what.

Maybe this problem is not interesting to you because you haven't considered catastrophic failure scenarios yet.

But things like that happened to currency exchanges and wallet services, why do you think stock exchange would be immune?

Anyway, I'm a programmer, not a lawyer. I cannot help you with non-trustworthy exchanges, but I can help to develop a secure trading platform.

By the way, it might help with trustworthiness checks indirectly: since smartcoin based trading platform won't do any checks at all, this would create a market for trustworthiness checks.

GLBSE wants to be everything at once, they offer some verification, sort of, but it is really half-assed, and its bundled with their trading platform. So people have no choice but to use it, and they don't think that 3rd party rating agency is needed.

But when trading platform is open to anybody, amount of bullshit assets will be so high that companies will have no option but to go to 3rd party rating agency. As many such agencies can co-exist, there will be a market, and so they'll compete to provide best services. I.e. you'll be able to check rating agency's track record.

The best way to solve social problem is to provide economic incentive, I think.

Can you be more specific on why you think a "color tag" in form of a published color public/private key pair and the use of it as a trace poses a problem in recognition and pruning? I fail to see the problem. (Apart of the "bloating" effect, but that's a small price to pay for an additional functionality, and the maximum required space is just an additional key verification...

It is elegant in solving a problem with accidents. It isn't efficient, yes. But OP_DROP adds some bloat too.

As for merged mining, you have to add hash of alt-chain into bitcoin block chain, right? Even if there are no transactions.

Imagine you want to have a million private currencies... So you need to add a million of hashes to each block... This simply won't work.

OTOH a million of colors is not a problem as long as there are no transactions.

You're forgetting that colored coins can exist on merged mined alt-chains. If transaction number becomes an issue, txn fees would force people to move to cheaper alt-chains, thus de-cluttering Bitcoin blockchain.

So ultimately it will only improve resource utilization efficiency as market will prefer most efficient solution.

I think this is awesome and applaud the effort. I am very excited at the prospect of satoshi's colored to denote USD-denominated debt in particular.


Do you trust GLBSE? I heard the SEC is investigating. Do you trust MPOE? I heard the operator is a pedophile/pornographer. Do you trust Mt. Gox not to keep accurate records of account balances and not freeze your funds? Wouldn't it be better if you could trade your MtGox USD in the blockchain?

Doing away with one level of trust is a major contribution.

Incorrect.  You misunderstand how merged mining already works.

You add one (1) merged mining merkle root to the block, covering all merge-mined currencies.  Each currency is an entry in the merkle tree.

That can then scale to a billion private currencies, without bloating the block.

Merged mining is obviously far more scalable than any solution that requires blockchain bloat, however minimal.

The downside is that you cannot have atomic transfers between a smartcoin holder, and a payment holder.

Any added data, OP_DROP or fake-pubkey or whatever, typically requires two parties to agree to maintain the format of the in-chain metadata.

But a bigger point is simply...  please please please do not encode data inside pubkeys.  Use OP_DROP or another visible solution.   In-pubkey makes it really difficult to detect and manage, for those of us trying to help the blockchain software :)

It could be useful to do this with a blockchain which is merged-mine-able but does not mint new coins.

That would throw out the entire confounding pricing/cost factor caused by miners minting coins, so we can look directly at how much it costs to have miners merged-mine a chain.

There are already several chains in which miners do not mint coins.

Each is individually looking at having to pay whatever "the going rate" turns out to be for having a chain merged-mined.

Maybe all such chains can gang up, between them paying to have one multicoloured chain merged-mined.

Maybe also everyone who is interested in colouring coins could provide an estimate / ballpark of how much buying-power their colour expects / plans / intends / will commit to spending on securing a chain.

-MarkM-

If this data is not included into main Bitcoin blockchain it doesn't mean that it doesn't exist. Miners who are participating in merged mining would have to process and send this data. So maintaining a separate currency via a separate chain ultimately costs you some resources.


Do you mean "does not bother people who care only about Bitcoins" by "scalable" here?


There is a contract for cross-blockchain trade. It's rather complex, though.

Err, it isn't "data inside pubkey", it is pubkey itself. I.e. if serialized pubkey matches pubkey associated with a certain color then this TXO might be of that color. I really do not understand what's difficult about comparing two pieces of binary data. You can use something as dumb as grep to detect potentially colored TXOs.

Are you talking about valid ECDSA keys, or random garbage stored as a guaranteed-to-fail pubkey?

Valid ECDSA keys. Issuer will create a keypair and will reveal both public and private key to people who need to work with that color. So it would be 100% legit 2-of-2 multisig transaction.

I also considered using random garbage and 1-of-2 multisig, but that's kinda ugly...

does this have anything to do with distributed transaction?

What is distributed transaction?

Transactions happened at more than places, i.e. each LTC->BTC trade requires two transactions, one on LTC chain and one on BTC chain. It's one atomic transaction, no partial commit.

I was under the impression, this colored chain scheme can be used for this purpose.

No, it doesn't help in this case. There is a contract to do trade across blockchains: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

One good thing about colored coins is that they allow us to represent different currencies within one blockchain, thus eliminating the need of trading across blockchains.

Ok. Thanks.

I think most people agree that BTC or LTC chain will be here for a long time. The way I see it, BTC chain is a database, LTC is another database. They each performs CRUD transactions independently.
 
As long as they do not agree to be bound by a common transaction API, attempts of making trade across them will be futile.

You can represent other currency whatever way you like, but this kind of representation will always be secondary when comparing to the native protocols.

DId you actually read the linked information?

Or did you simply fail to understand it?

There is no representation of one type of coin on the other's chain.

There are simply transactions that can only be completed using infomation that also allows the other chain transaction to complete.

Maybe you need to study it more until you understand what it is saying?

-MarkM-

I know exactly what is being discussed. Sorry, it's not my problem if you failed to understand what I was saying. 

This is not the solution I was looking for to solve automated transactions among existing alt-chains. Those chains can't and won't delegate their transaction handling to whatever the modified btc chain you come up with.

 

I think I do not understand what you want, or possibly it might be more accurate to say I do not understand why.

It seemed to me the linked page showed how two existing chains can perform transfers of their own coins on their own chain in such a way that either the transactions on both existing chains happen or neither of the transactions on either of the existing chains happens.

So for example if you want to sell me some litecoins for some bitcoins we can set up transactions that will prevent you from getting my bitcoins without me getting your litecoins, and/or we can set up transactions that will prevent me from getting your litecoins without you getting my bitcoins.

If trading on two existing chains is not what you want, then what is it you do want?

-MarkM-

It IS what I want.

Having all coins on the same chain, both colored and not-colored, will of course enable the trading. The part I failed to understand is how it could make the cross-chain conversion transaction as part of the atomic transaction.

Maybe trying to apply database distributed transaction theory is a mistake here. It won't be applicable if all trading parties agree to use same modified client and thus to follow a super-protocol. I still suspect there will be loophole that can be exploited between the transaction on the native chain and the one on the color chain. Just a gut feeling, I can be wrong.
 

They do it with crypto tricks, so if there are loopholes in the crypt used I guess it could be vulnerable but the basic idea seems to be if they sign for your coins the data that puts into that blockchain suffices to let you compute what you need to use on the other blockchain.

So presumably as long as you get the math right, including making sure they really do give you the data they are supposed to at each step, it should be about as secure as the blockchain the coins are on.

-MarkM-

Thanks. Looks like I do need to read more on this. I want to see how exception and rollback are handled, if something goes wrong and trade fails.

The main difference between a new altcoin to colored bitcoins in order to create/maintain/exchange :
A new altcoin needs sufficient clients/nodes/miners to support its security
To scale mining in altcoin you need miners to support merged mining in that altcoin
You need a client/exchange that support distributed contracts to exchange one coin to another

With colored bitcoin
Colored bitcoins are based on bitcoin (or the chain they are on) security, so transaction are as secure
No need to maintain any mining of its own, miners are agnostic to colored bitcoins
To send/receive colored bitcoin all you need is a client support

I believe there is a need for both solutions, and all altcoins can support colored altcoins, the altcoin is flexible to changes in its blockchain and colored altcoin relies on existing blockchains.
Recoloring, or exchanging one color is simply an atomic bitcoin transfer, one client send another Color X and gets Color Y, with the price discovery of the rate as simple as calculating X/Y.

“That’s been one of my mantras — focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” Steve Jobs

Here's a thread specifically about order-based coloring algorithm: https://bitcointalk.org/index.php?topic=114571.0

Everybody who is interested in coloring algorithms should watch it as I'll post updates there, not here.

How do you know whether any of the inputs are coloured at all?

Don't you have to scan the entire blockchain looking for some special kind of transaction that by convention represents the inauguration of a colour?

Surely if you miss such a transaction you are not properly colour-enabled, and it is only by missing (or forgetting) an inuguration event that you can fail to know what the colours are of all inputs and outputs in the entire blockchain?

Maybe you need a backwards colouring algorithm, that can backtrack each input until it either is clearly a mixed colour or is traced back to the inauguration of its colour or arrives at the genesis block of the blockchain and thus is a pure original uncolouredness?

Or are colours external and ubiquitous, for example such that anyone can point at any transaction anywhere and say that there is the colour I mean, identifying it by the transaction number or possibly the transaction number and output number of that transaction, and like taint they have created specified in that after-the-fact moment a colour within that moment's context?

(Like taint: any time any one can claim any output of any transaction is criminal/illegal/tainted and it is from there traced onwards through the chain.)

-MarkM-

Coloring is done recursively starting from "genesis transaction output". Genesis transaction outputs are defined in configuration. E.g. you'll have a file saying that "transaction XXXXX output 0 is color YYYY also known as USDcoins".


That's one of ways to do that, but I'm currently for configuration file approach... It doesn't matter much because approaches are compatible with each other: we can start with configuration file (or even colors defined directly in client code! That's what my proof-of-concept does), then, maybe, define a way to import color genesis data directly from blockchain.

Basically a low level color tracking engine is told what it should track by some higher level. Which can be anything: configuration file, blockchain scanner, DHT, RSS feed.. Whatever.


If genesis TXOs are defined via blockchain it's simply not possible to miss it if we have access to a full blockchain.

However I'm currently considering implementation where colors are tracked at will. If you don't care about color green, don't track it. Nobody will send you green coins. But if you need to accept green coins, you import green coin definition and client software performs blockchain scan and starts tracking them.


This is exactly how it works now.

The only question is when computation is done. I think it's a good idea to cache color information in color db so you won't have to rescan blockchain repeatedly.

But it's also possible to run it on demand.


Yes, this is how I think it should work. But it's very likely that you want to define new color using a special client software which would create txo with appropriate amount and will generate definition which refers to that txo. The reason is that software will ensure that you won't accidentally spend your freshly colored coins.

But you can do it using blockexplorer if it's your thing... That's how I made test color definition in code, actually.

How close is this to being used for an actual security and have you seen this guys work - https://bitcointalk.org/index.php?topic=117630.0

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

If there is no special entry in the blockchain that recognisably inaugurates a colour, you will not even know whether your local pretense that a particular output is a particular colour is actually the case or whether, rather, your purported colour is actually a confused mish-mash of colours already inaugurated earlier in the blockchain.

Maybe that does not matter, maybe it is okay that people who are aware of more colours than you are realise that your company's shares, for example, are actually a mix of 33% company X's shares, 45% company Y's shares, 20% company Z's shares, 1% no-longer-coloured coins and 1% never previously coloured coins?

-MarkM-

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.

So I am going to "forget" my Best Grade A Company On The Chain corp because I am considering dabbling in the nanobit-stocks market by picking up a few of your newly made up no-body-shares?

I doubt it.

All you are doing is forcing people to throw away estsblished, valuable shares if they want to participate in the paonzi of the nanosecond market.

Really, check the damn coin is not coloured before trashing it.

Otherwise someonje is going to trade their birthright for a mess of pottage, as the swaying goes, by not understanding the value of the coloured coin they are about to trash to create a worthless pretend stock to see how your system works, and stuff like that. (n short, they will find out the hard way it does not work...)

You seem to be basically using taint, not colour. Taint anyone can claim yeah that output there, that is stolen coins!

Colour should be something in the blockchain itself that announces the genesis of a new colour.

I don't think taint that follows the colour algorithms as to what/how it taints is at all the same thing as an actual colour.

-MarkM-

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.

Ah, you aren't turning multicoloured coins into a generic mucked up colour then?

I can create a source of red coins, send them two two different places, then invent blue coins, use one place's red coins as the coins to turn into my new colour blue, then send some red and some blue to a third place and that third place will be switchable from being red or "purple" depending on whether I choose for a moment to follow red or to follow both blue and red?

-MarkM-

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.)

Sounds like we're going to get a really messy bunch of non-fungible palimpsests, with almost every coin in everyon's wallet coloured hundreds of different colours depending on which of hundreds of thousands or maybe even millions of colour-definitions you try to load into your client at once, with massive numbers of those colour-definitions conflicting with each other and a growing frequency of news articles describing yet another person who had not heard of some obscure but extremely valuable security so sent it as fees to miners instead of running a coinoogle search for any and all possible coin colours they could choose to view their coins a and a coinfroogle search for which of the possible permutions of colours would result in the highest value for their wallet as a whole.

I hope this whole colour mess is not how smart property was envisioned. I had thought smart property had seemed like an actually quite smart idea but if it is like these colours what happens when some poor sod uses what he views as his garage door opening colour only to learn the hard way that someone else had already designated its ancestors as a demolition blasting-cap activation colour?

In short, I had thought the uniqueness of each share ceritificate, automobile ownership etc "colour" would be better preserved, so that when you created a "colour" representing ownership of your car it would not turn out to be someone else's car ownership certificate too.

Or is that intentional, that you can end up for example with many many cars whose ownership is all transfered by the same satoshi or coin or whatever?

Baically I thought how it was to work is blue means my automobile, red means your automobile, green is our next door neighbor's automobile and so on, one "colour" per item of smart property?

-MarkM-

LOL.

No, with order-based coloring we won't get into such situation because coloring information is easily destroyed when coins are mixed. You can only get into funny situations only if people make funny coins.

If it's still a problem we can add mandatory tagging, then coin's meaning will be totally unambiguous.

So it's more like same molecules of gold being reused for various types of coins rather than "palimpsests". Perhaps you can find that your Krugerrand's gold is related to gold used in ancient Rome through chemical analysis, but that doesn't make any difference.


Hmm, perhaps we should implement multicoloring and satoshi-tracking just for shits and giggles :)


Again that's kinda unlikely scenario. To activate a wrong property you need:

1. Somebody to transfer you a coin which controls smart property. Erroneously, since otherwise it is a legit trade. That would be sort of hard because he'll have a separate wallet for smart coin. So, well, one needs to extract private key from that wallet, import it into his main wallet and send it to somebody else. Accidentally. It's probably easier to shot yourself in the head twice accidentally.

2. Property needs to be aware of transfer of ownership. Unless you tell it explicitly, it should be a very smart property which is connected to internet... (In Mike's example, new owner needs to prove to his car that he is indeed a new owner.)

3. Smart property is activated with a message signed with owner. So a new owner needs to

a) know what message unlocks his property
b) sign that message
c) send this message to property

Again, it's unlikely to happen accidentally :)

Additionally, it's possible to disambiguate transfer of property with OP_DROP message tagging.


Why not, they can all track same coin. But that must be intentional.

I.e. normally one who creates smart property would make a single output tied to it.


Right.

Actually I see colored coins as an extension of smart property protocol. It is smart property when you have one indivisible unit. Its ownership might be controlled with just one output which has 1 satoshi, for example. Or even zero satoshis, apparently you can transfer an output with zero satoshis in it. (See Mike Hearn's "distributed bond market". Bonds are tagged with message, by the way, so no ambiguity is possible.)

With colored coins value of output represents how many units you own. So instead of making 100 outputs each representing one bond, one can make just one output with 100 satoshis in it, with 1 satoshi representing one bond.

So colored coins just allow one to represent ownership of many units in a more compact blockchain format... It makes a lot of sense for things like currencies, bonds... But not for cars, I guess :)

It works for cars...  as long as the car's security system is keyed to anyone who can prove they are the holder of the smartcoin.  Your mobile phone can easily generate an ECDSA-signed message proving this, given the proper key.  And Wired articles like this one (http://www.wired.com/autopia/2012/10/silvercar/) show that it is feasible near-term for a mobile phone to be your car key.

It should be straightforward to trace a 1-satoshi output through the chain, to prove to the car's bitcoin API that the mobile phone is last holder of that coin, following standard colored coin rules.

Frankly, multiple colors of coin are not that interesting to me.  The main point is simply proving that (a) a given txout represents car ownership, traceable back to the "root property," and (b) you have the key associated with that txout.

To me, the basics are fairly simple: Within a single bitcoin transaction, you must distinguish between a smart property transfer and payment transfer, and ensure the two don't mix.  You must also ensure smart property transfers don't mix.

Yeah, I know. I just meant to say that we do not need to denote "number of units" when we work with physical property like cars: one car is one unit which is controlled with one output. Thus output's value isn't relevant, it can be anything, even zero.


"Multicolored coins" are just as theoretic oddity which can arise from ambiguity in a coloring scheme which doesn't use explicit tagging.

As I'm thinking of using coloured coins to manage a 180(GH/s) mining asset and pay dividends using them.  Would it be possible to create 10,000,000 coloured (satoshis) coins from BTC1.00 only giving out 180,000 of them and only have dividends paid to the 180,000 given out while the remaining 9,820,000 coloured coins don't receive any dividends until they are given out in transactions.

Only the issuer needs to have any block chain bulk, so the Asset Issuer ID, the Bitcoin Address -  are the same thing.

Over in Open Transactions land there has been talk about integrating something similar to killerstorm's (kthbye) colour coined idea.

Here is the pastebin (I wrote, randy copy edited):

http://pastebin.com/raw.php?i=ygVyaBPL

It involves a non-trivial amount of work...  However it will make OT and Bitcoin fundamentally interchangeable! :)

Each smart property token has its own separate block chain storage, just like individual bitcoins.

Additionally, if you want a fully auditable system -- we do -- then you need a commonly agreed way to make payments to token holders (asset owners) viewable and traceable in the block chain.

That way, you can see which issuers are paying as they claim.

Sorry, joining this discussion kinda late.  I just read through this thread and didn't see a few things that I was hoping to comprehend.  Maybe someone can link me to where this was discussed.

At least in terms of smart property, the idea that mixing color is destroyed seems dangerous.  Mainly because a subtle client bug that still creates valid transactions could end up destroying property.  When you say that mixing colors destroys coins, that means shares of a company can go *poof*.  Not likely to happen by accident, but I bet it will happen at some point.  To someone, somewhere (wrong color ordering, fee subtracted from the wrong place, colored accidentally ending up in the tx fee).  It could possibly even happen maliciously.   I'd really like to see that coloring is preserved, and that mixing 1 satoshi into your 10 BTC of colored coins does not destroy it.

So what is wrong with diluted colors?  i.e. what is wrong with this scenario?

• I create a 200 BTC genesis tx for "green".  Let's say that green represents shares in a company worth $200,000
• I distribute 10 BTC to each of 20 people who now own 5% of that company.  So that 10 BTC is worth (10*MtGoxRate + 5%*CompanyValue).  At the current price of $16.70/BTC, that means those 10 BTC are worth $10,000 + $167 = $10,167
• I send someone a 100 BTC transaction, using 90 BTC of uncolored inputs and this 10 BTC green input. That person now owns 5% of the company contained in 100 BTC.  (100*BTC + 5%CompanyValue)
• That person can now sell someone 40 BTC from that 100 for (40*MtGoxRate + 2%*CompanyValue).

This seems deterministic, unambiguous, and retains the transparency.  There is no ordering, or need to understand specific color rules.  Obviously the more that coins are diluted, the more annoying it is to handle/sell them, so users would be naturally avoid mixing them, but there may be valid reasons for doing so.  At some point the dilution can be so much that there's no point, anymore, and the color is effectively destroyed (perhaps below 1% density).  But it wouldn't result in a loss of property without them passing through a lot of oblivious clients.

I'm sure I'm not the first person to think of it.  Can someone explain the drawbacks to this method or link me to where it's discussed?

EDIT: etotheipi, never mind, I can't read... (took mixing as talking about divisibility)

I think you need to first ask the question "What does an SPV client need to validate a colored coin?"

The coin in it's present form will be in the txout set, but the history won't be, so the client needs to get a set of merkle transactions - a tx + the merkle branches back to the block header - linking the current txout representing the coin to the transaction that issued the coin in the first place.

But once you have that, why does divisibility matter anyway? Just have a standard to distinguish colored and non-colored txouts in a transaction - odd/even number of satoshi's works fine - and as you walk the transaction history dag back to the issuing transaction compute the percentage of total colored value that each txout leading to you represented. If divisibility is ever a problem in one of the transactions just add some value in the txin that isn't returned in change. Here's a concrete example:

Alice issues her "Alice Mining Bonds" and manages to sell %10 of the initial issue immediately to Bob and another %10 to Charlie: (for simplicity I'll leave off the odd-even satoshi's trick)

Charlie then turns around and sells a quarter of his share to David, and keeps the rest:


Now David has a txout worth 0.0025, and the merkle tx from Charlie and finally the initial issuing tx. He knows that he got 25% of the value of the tx Charlie gave him, and Charlie got %10 of the value of the issuing tx; %25 * %10 = %2.5 of the initial bond issue. This technique makes paying for mining fees easy, doesn't force you to tie up Bitcoins just for bonds, allows whatever divisibility is required, and having the merkle tx's available makes implementing bonds on SPV clients easy anyway.

FWIW I'm planning on having my Fidelity Bonds (https://bitcointalk.org/index.php?topic=134827.0) idea work this way.

Incidentally this also suggests a better hashing algorithm for transactions: hash the transactions themselves as some sort of merkle tree. It'd work really nicely if the intermediate hash values included the sum of the tx values under that node in the tree, so the fact that the tx was accepted into the blockchain was proof of the total txout and txin value, without having to actually have copies of any particular txin or txout. Specifically for a tx looking like this:


The hash of the txin's would be calculated as H(0.6 | (H(H(txinC) | H(0.3 | H(H(txinA) | H(txinB))))), the txouts similarly, and the final tx hash H(txin_root_hash | txout_root_hash | locktime etc). (obviously extend this with HMACs and what-not as required to deal with non-ideal hash functions)

Now for a really big issue transaction the merkle branches within the transaction itself are enough to prove the ratio of your bond vs. the issue as a whole. If the issue was for a few thousand bond-holders this is a big deal.

Also this idea can be extended to the transaction values within a block to make it harder for miners to get away with inflating the number of bitcoins to SPV clients, who now just have to pick random parts of the transaction tree to probabilisticly audit for inflation fraud via detecting non-existent transactions. Similarly SPV clients can just add the the total txin and txout values and check that the change in total number of coins from the previous block header is equal to the current block reward. Fraud due to a non-existent transaction can be broadcast by broadcasting the merkle branch suspected of not actually existing, and the broadcast can be quenched by anyone broadcasting a matching transaction. If any SPV node sees an unquenched fraud notice, they don't mine to extend that block further.

Of course, none of the above is implemented yet, but it can be implemented as a merge-mined soft-fork, the same way all the "hash of the txout set" proposals work.

EDIT: cleaned up the stuff above and posted under it's own topic: https://bitcointalk.org/index.php?topic=137933

Well, if we are dealing with cryptocurrency shares of a company can go *poof* in many ways. Wallet lost, sent to wrong (particularly, non-existing) address.

We can assume that if coins got mixed it's also likely that they went to a wrong address.

What's the sensible reaction here? I'd say destruction is a feature, not a bug. Original owner can prove that he owned that shares and he can ask for replacement from issuer. Issuer can investigate the situation, and if shares were indeed destroyed he can issue some new ones and give them to this shareholder free of charge.

However, if coins are not destroyed, they might end up in a wallet of a person who isn't supposed to own them, and you cannot fix that if that person does not cooperate.

So I think it's better to destroy color label in case of a dubious transaction and rely on manual resolution.


Considerably more complex implementation: each transaction output now has a spectrum rather than a single color, and value for each color is represented by infinite precision fraction. I.e. you can end up owning 230918409134/21332840932904832984 of a company.

But, importantly, it doesn't really address the problem: if coins were diluted due to some software problem, we can't be sure that, diluted or not, output went to a correct address.

Also, you can't undilute coins, if they are mixed, they are mixed forever.

Note that with my approach towards mixing, automatic un-mixing  is possible, it just needs to be issuer-mediated.

For example, issuer publishes unmix-this-please address. If there is a fuck-up, person sends his mixed coins to that address, issuer transfers them internally and returns some part of coins via his issuing address, thus making them colored again. The rest is returned via a normal address, which leaves them uncolored.

If several colors are mixed, issuers can use deterministic satoshi tracking algo to verify correctness. (The idea is to assign an unique number to each coinbase satoshi, tracking it through transactions and fees. Then color of satoshi is preserved under all transformations.)


Eh, what? If you more than one color together it ALWAYS get diluted?

Then there is no way to implement decentralized exchange via atomic coin swapping, for example. Not to mention that even sending coins is problematic (i.e. you cannot pay a fee and get change in same transaction, you'll have to prepare utxos with exact change value in advance).

IMHO decentralized exchange is colored coins raison d'être, so any implementation which doesn't allow that is largely useless.


People mentioned dilution as an alternative to destruction in case of mixing, but not as a coloring algorithm on its own.

Other proposed alternatives are deterministic satoshi tracking (order-based) and color tagging.

I think the key is that color destruction is provable, and issuer-mediation can fix it.  But, when 10% of the shares of a company are destroyed, how do other 90% owners of that company know what the new issuance will be?  Is it a subscription service that the color definitions can be updated?  Do clients try to track all related coins and know what the total amount is?  Without new color definitions other users may believe that their own shares popped up in value by 11% when those 10% shares were destroyed. 

We haven't settled on this yet, there are several proposals and no implementation. (There is a lot of discussion in bitcoinx google group.) Proposals:

1.Issuing address: All coins sent from a certain address are colored. So company's officers which have access to private key, they can create new shares. You have to trust the company anyway, otherwise shares are worthless. So you can trust that they issue correct amount. The problem is that private key might be stolen and thief will issue and and try to sell unlimited amount of shares.

Possible ways to mitigate the problem:

• Cool-off period: coins are not considered valid for, say, first 144 blocks, and so people have time to react to new issuance. If issuance is not authorized, they will freeze all trade and find a way to fix this, e.g. replacing color
• Limit total number of coins in color definition, then client will consider freshly issued coins only if it sees that some shares were destroyed
• Better protection for private key: use multiple signatures, offline storage etc.

2. Color definition replacement: Company creates a new color definition, signs it and uploads it into color directory. Client software periodically checks for updates. If definition is updated, client software asks user whether he trusts new definition, and user might do some out-of-band check before he makes color definition active. Meanwhile, if you haven't updated your color definition and others did, you won't be able to trade these coins on market as colorid is different. So you cannot accidentally purchase newly issued coins on market if you haven't activated color definition replacement.

3. Color definitions embedded into blockchain. I'm not sure if anybody is advocating that right now, so I won't go into details.

(I'm personally for color definition replacements... Color definition is like a contract, and contracts are meant to be amendable.)


ArmoryX creates a list of all colored transaction outputs, I think it won't be hard to calculate total amount, but it doesn't do it now.


Well, if we are talking about shares, I don't think they were destroyed...

On a fundamental level, we track ownership of an asset through a chain of digital signatures, each signing the transfer.

If coins were mixed then transfer did not happen (analogy: a garbled message was signed), so previous owner still technically owns them.

From this point of view, person who signed that color-mixing transaction still owns shares, but he cannot transfer them because of limitations of the protocol. So his shares are effectively frozen, and issuer's action is needed to unblock them.

But that's how we humans look at it... Client software will simply show 0 balance on both ends, as it shows only what can be transferred. So human is supposed to check blockchain to see what happened and fix the situation. (Of course, it can be automatized, but I doubt it will happen so often that it makes sense...)

By the way, while we are here, dividends should be paid to addresses which hold shares by a certain block. And same thing applies to voting. If dividends are paid at block 210000, software should create a list of owning addresses and their shares at that time. If somebody transfers shares in block 210001, he won't receive block-210000 dividends. (All this stuff with votes and dividends isn't implemented yet, but I think that's how it is supposed to work.)

@killerstorm - i've been following the various threads for this colored coin project and there is one thing that is really confusing to me. you've mentioned quite often that combining different colors into the same transaction would in fact make them "uncolored". but then you talk about using ordered inputs and outputs with various coin colors in the same transaction.

so is it possible to have multiple inputs, delivered to multiple outputs for the SAME destination address ? so then the uncoloring would only happen, when several colored inputs where delivered to the SAME output? (this comes from my still elementary understanding of the anatomy of a transaction)

thanks.

Yes.


Yes.

Basically they get uncolored only if transaction violates order-based coloring rules, i.e. it was created by nonconformant software (e.g. by client which knows nothing about coloring).

interesting. thanks for the answers. still so much to learn.

also, i think you mentioned that its possible to have transaction atomicity in bitcoin's current implementation. is that true or is it planned for a future release?

FYI - i originally found your thread in a search for bitcoinjs. it's a wonderful library and so far i've been really happy with the results. i've been able to successfully customize its database logic (something i just couldn't manage with bitcoind or bitcoinj) to suit my specific needs. this may overlap with your coloring project so I'll be keeping on close eye on your implementations as well as where i can contribute.

Also, have you looked at https://github.com/bitsofproof/supernode (https://github.com/bitsofproof/supernode). its a modular implementation of bitcoind written in java. i love the api and the fact that it can run over a rdbms (although i haven't gotten that to work yet). the SQL capability "may" give you better performance for your blockchain queries (although i admit that i don't quite fully understand your protocols yet). i have some ideas that i'd like to share once i have a better understanding and i'll certainly keep your needs in mind during my own coding efforts.

cheers!

ArmoryX colored coin client already uses there atomic transactions for p2ptrade.

Generally speaking, Bitcoin transactions have multiple inputs and multiple outputs from the start, so it was always possible to use them for atomic transfers. The only diffculty is construction and signing of such transaction.


Yeah, I've heard about it, but I'm not a big fan of Java and RDBMS stuff. Perhaps we might use it when we'll do something enterprisey :)

Okay, so far so good. I'm really liking the idea of colored coins (vs. what I originally had planned for my own purposes) more and more.  This way is a hell of a lot more work, but if it follows a clear standard that can then be improved upon by the community, I'm ALL for it!  However, I want to make sure I'm following the "correct" protocols that you've defined (or have been agreed upon). I'm getting lost in the amount of threads on this subject and find myself making multiple circles just looking for up-to-date information. Is there a static page or a wiki that has everything clearly defined (and is up-to-date)?

To make sense of all the information I created an index of relevant links as well as a faq.  These are for my own purposes, but I'd like to be able to read and contribute to a community page (if one exists).

thanks,
s.

This may be a dumb question but could Ripple and its 'exchange' features be used for coloured coins if there was a trusted Gateway for coloured coins?

retep wrote a comment in github discussion of anti-dust patch ( https://github.com/bitcoin/bitcoin/pull/2577 ):



I want to comment on this...

First, I don't think that anti-dust patch causes problem for colored coins... People should just accept that creating units has non-zero cost.

Suppose you want to issue USDcoins (a pegged currency). You can make a unit such that 50000 satoshi = 1 USDcoin.

Then to create 1 USDcoin you need $0.065 worth of Bitcoins at current exchange rate. E.g. to issue $10000 in USDcoins you need $650 worth of Bitcoins. Is it a problem?

It might be a problem if you're 12 year old scammer who doesn't get enough money from parents, but if you're a honest issuer getting Bitcoins upfront won't be a problem.

Then, Gavin's patch would ban sending less than $0.11, while retep's patch would require to send at least $1 in USDcoins.

Is that a problem? I don't think so... If you need to send something on $1 scale, fees will bite you anyway... At such scales off-blockchain transactions can be useful.

Divisibility might be desired for some uses, such as issuing shares which might fluctuate in value (e.g. see what happened to Berkshire Hathaway), but I don't think it is a crucial issue. If anything, there is a mechanism for issuer to re-issue shares and exchange old shares for new shares.

---

Another question is why we don't use retep's coloring mechanism... Well, there are several reasons for that.

First of all, we considered something similar (color tags in value or in scriptPubKey), but:

1. Odd/even trick works only for one color in transaction, which rules out plenty of interesting things, such as, for example, exchanging GOLDcoins for USDcoins, Ripple-like multiparty transactions, multiple issues and assets with multiple issuers.

2. There are two problems with tags in scriptPubKey: they add to blockchain bloat, and they need a specific scriptPubKey format.

So, basically, we need to define how output is color-tagged for each scriptPubKey form... Which is a bad thing, I think.

Only fixed number of script forms can be used, and adding more will require a colored coin analog of hard-fork, i.e. an upgrade for all colored coin clients.

On the other hand, order-based coloring does not require any particular form of script. You can use P2SH, not use P2SH, use multi-signature transactions, any contracts... It just works (tm), and requires no hard forks, ever.

So the reason to use order-based coloring instead of color tagging is minimal overhead and maximum flexibility w.r.t. advanced scripts.

Another reason is complexity... Order-based coloring requires just a couple hundred lines of code to implement, and so does modification of wallet. p2ptrade implementation is just 500 lines of code in Python. (It is pretty much trivial to compose multi-party transactions, see here: https://i.imgur.com/UIFfvr8.png)

On the other hand, implementing retep's contracts would require like 10000 lines of code... It's not only a problem to write such code, it is a problem that there will be a shitload of corner cases and, thus, bugs. (There is a reason why we have colored coin implementations (I think we now have something like four of them), but no fidelity bond implementations, right?)

Even contract value accounting is a problem:


To implement this exactly, you need infinite precision rational numbers (SUM(vout) can be anything, right?)... and this is not what I want to see in finance software, let alone crypto software...

One could require SUM(vout) to be in form 10^i for some integer i. But even then you need bignums to work with these numbers... Suppose somebody clever will divide shares into 0.1 and 0.00000000000000000000000000001, and will add them together. How much memory do you need to store this value?

So, to summarize, retep's contract mechanism offers small advantages, but big disadvantages, and we aren't going to use it.

(Also there is a desire to get shit done without spending years on discussion. Even if that accounting mechanism was clearly superior, solution which is "good enough" shouldn't be replaced with something better just because it is better.)

No, but an issuer could issue IOUs in both networks. For example, Bitstamp could issue bitstampUSD as colored coins, to be traded atomically for BTC just as they issue bitstampUSD in Ripple to be traded for bitstampBTC or XRP.


It has near zero cost in Ripple and could perfectly have near zero cost in Bitcoin.


I don't think Bitstamp are scammers. In the other hand, I want to be able to buy 110.5 bitstampUSD for 110.5 usd instead of 110.5 + (price of bitcoin in usd/ dust_constant) usd. And then be able to buy 1 BTC for 110.5 bitstampUSD. Or 0.89 btc for whatever its price is at the moment in bitstampUSD with 4 decimals for USD precision.
With this new "soft-rule" that just saves miners the hurdle of paging the UTXO efficiently instead of want it all in RAM, what I think will happen is that Bitstamp will just not issue usd IOUs as colored coins, and save their users the pain of dealing with non-divisible digital numbers.

I think 5000 satoshis reserve for an atomic indivisible unit is too much, and I think 1 satoshi is too much too, we don't need underlying satoshis if we change the protocol.

If you pay your fees you can use the chain; you don't pay fees, you don't.

That should be enough.
If fees are not enough, the problem is bigger than what can be "solved" with this patch.

From here: https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners#Ripple_is_a_payment_system


Well... It might be zero cost if people run servers for free, but I don't see how it can be sustainable. Of course, OpenCoin is interested to keep their servers running to create demand for XRP and sell those XRP for profit.

But how is this decentralized?

Seriously, it sounds like a scam...

In Bitcoin, fees are honest: processing a transaction and running a node requires resources, and people who want to send their money pay...

But if you get some service for "free", there must be a gotcha...


Well... It can work that way if Bitstamp agrees to have some exposure to BTC. E.g. suppose Bitstamp gets 5 BTC, colors them as USDcoins and sells USDcoins for $10000. Bitstamp now has $10000 in reserves. Time passes and users redeem USDcoins. Bitstamp gets 5 BTC back.


Problem is definitely bigger, I think nobody doubts that. But solution is complex, if exists at all.

https://ripple.com/wiki/Gateway_Integration_Manual#Gateway_Revenue
https://ripple.com/wiki/Transit_Fees

Every gateway will probably want to be also a server.

Thanks.

If I understand correctly, using a gateway costs you non-negligible amount of money.

Is it possible to use Ripple without using gateways? Like, issue your own IOUs etc.

Is it possible for gateways to ignore transactions which aren't beneficial to gateways?

I see two possibilities:

1. Either people are forced to use gateways so that in the end they pay more.
2. Or these almost-free transactions are not good for gateways and they'll try to curb them.

Yes. They can also do it for free, if they want.

Yes, every user can do mostly what gateways can do.
A gateway uses "Rippled" to more advanced things.
If they will do as they said, Rippled and Ripple server will be open source as the client is now.

I don't know, I'm a fan of the project but I'm not so deep in it ;)
Anyway I can't see the reason so that a transaction won't be beneficial to it.

As it seems everyone can be a gateway and chose which fee to add (or not) to transactions.
It should be a completely free market.

Anyway if you want you can try it now, just register an account and deposit some XRP from Bitstamp or someone else.

Checkout bittorrent and Tor.
Gateways and merchants have a bested interest in running their own validator node.

http://bitcoin.stackexchange.com/questions/7567/what-benefit-or-incentive-is-there-for-someone-to-run-their-own-ripple-client-or


This exposure is unnecessary.
This doesn't solve divisibility. If the represented assets ever go below their BTC underlying "reserves", the assets will never be redemed, as people would "cash the BTC out".


If you need to charge for the UTXO (and I don't think so), a flat demurrage fee would better than an arbitrary "reserve" or minimum output.


You need to separate the network of validator peers from the financial network inside ripple.
Every user can issue. Gateways are just "more official" issuers. http://bitcoin.stackexchange.com/questions/7620/how-does-a-gateway-iou-differ-from-any-other-iou-on-the-ripple-network

Gateways will usually be also validators, but it's not a requirement.
If ANY validator acts dishonestly according to the rules (for example, pretending it hasn't received certain transaction) the rest of the nodes will ignore him.

Digging up this comment, as it is a very sane and important one. The issues described are attributed to an immature market. No stock exchange has fully attempted "legitimization", and to my knowledge, I'm part of the only effort to separate the investment bank role from the exchange role. For a while now, I have explained that exchange operators should not be running their own securities, and that an investment bank's role helps to align interests between the Exchange, Investor, and listed Business.

In context, I don't see how decentralized concepts fix any of these problems. People will always need familiar/popular sources to provide (likely) trustworthy/valuable securities. IBs and the businesses they underwrite will always need reliable core audiences to sell to. If you break all these things into pieces, it places everything into the "wild", and arguably leaves us with a less useful system, with more, smaller, points of trust required.

Ultimately what is the core problem being solved, and is that problem actually solved, or simply moved to another point. For example, the stock exchanges close due to fear of SEC enforcement. Decentralized solutions then remove need for an exchange, but does now the SEC simply focus on bitcoin IBs, or the privately listing businesses instead?

Centralized exchanges are, obviously, the weakest points, in many ways.

It is possible to construct rating agencies (we call them this way now) in such a way that it's pretty much impossible to attack them. You can operate one fully anonymously, simply signing messages like "After performing checks X, Y and Z, I believe that company ABC is trustworthy". How can they shut you down?

Of course, it is always possible to go after individual business. Ultimately, it will be the weakest part.

But if we remove these other weak parts (which were actually unnecessary), it's possible to focus on the actual problem: making it possible for companies to raise capital without violating laws.

It might be possible either through registering companies in jurisdictions which allow that, or using proxies/intermediaries. However, IANAL.

IMHO businesses should not be directly managing their own listings. There are conflicts of interest and issues with ignorance to how to perform the role that are quite considerable. This inevitably puts IBs back into the picture, which begs for centralized exchanges to exist to separate powers. Either way, the SEC still has a focal point, and thus the decentralized system is no stronger than the current one in that regard.

This unicorn is a moving target. You can get close to it, but I'm not sure you can ever touch it.

I suppose what I'm saying results in suggesting that the solution is actually for a Bitcoin Stock Exchange to make the effort of trailblazing the path of legitimacy, and for Investment Banks to do the same. If decentralization motivations lead to giving those two powers better and more accountable tools, and lead to shareholders having a default contingency plan, great.

In that sense, do these decentralization efforts boil down to creating digitally verifiable stock certificates, and nothing more? If so, I think many people cheering for the effort have the wrong impression of what the movement will achieve...

In between, may I ask, if you have a kind of time table or a close-date for an alpha or beta release? Or not a clear implementation date yet?

What do you mean by "centralized exchanges"?

IBs (or intermediaries/proxies) will assist business with public offers, paperwork and whatnot. I think a good model for it is PicoStocks, and, maybe, MPEx. (But they are bundled with a trading platform.)

Rating agencies will help investors to find worthy securities: they can work with businesses and their representatives to perform audit, independent valuation analysis and so on. In the end, each rating agency will create a list of securities it believes are good.

If we assume that decentralized trading platforms exist, I see what role "centralized exchanges" might have. A security doesn't need to be listed in a specific place.

It can be listed on:

• rating agency's site (it is probably preferred, as rating agencies have strongest incentive to provide proper information)
• IB's site (they have an incentive to promote businesses they work with)
• own site of a company
• on bitcointalk

No matter where user gets information from, he can trade shares of that company using this decentralized trading software.


Who SEC will go after?

Are you aware of model which is used by PicoStocks?

They bought shares of CoinTerra, a private company registered in US, and now as a company registered on Marshall Islands they let users trade virtual shares based on real CoinTerra.

Do you think that SEC has an authority to close PicoStocks?

Proxies are not in any way unique to cryptocurrencies. E.g. Goldman Sachs created a fund as a proxy to Facebook shares when Facebook was private.

Then there is SecondMarket.com:



Look, I'm just making a tool, and I anticipate certain uses. But people will likely use it in many different ways, and it is hard to predict what will work and what won't.

Yes, there is no clear date.

Unfortunately there was a problem with recruiting developers, i.e. barely anybody was working on this for months, but there is some hope that it will change soon...

We'll probably have something available this month, but there are no guarantees...

Why don't you try to crowdfund the project and then choose and hire some developers for a compact implementation? Due to recent events, timing is great.

Maybe they could list on an exchange ;)

Well a group of respected known faces of the project can create a multi-sig secure bitcoin address and then call for a kind of crowdfunding, it could be in IPO or any other form that suits the project characteristics better and also includes regulatory concern.
Mastercoin did such an IPO and got a huge funding capital, it was during August when BTCT and Bitfunder were working normally, a crowdfunding or kickstarter for coloredcoin should bring more attention in this desperate time.

We already have funding... 200 BTC was pledged by sponsors for a complete implementation:

1. 100 BTC for NGCCC: a client which can be used on desktops and servers
2. 100 BTC for WebcoinX, a web client

It is still hard to find developers!

100 BTC will buy you only 1-2 months of work of North American/European programmer...

But to have a good progress, we need developers who already have in-depth understanding of the Bitcoin protocol and everything which goes with it, and who are qualified to work on project like this. Of course, good devs are already working somewhere, and it's unlikely that they will consider leaving their current work to have 1 month gig. (Cf. J. R. Willet: he didn't abandon his work even though he got something like $600k to develop Mastercoin.)

So there are only people who can work in their free time, on weekends, etc. And, understandably, it doesn't result in fast development.

I think it's worth noting that we already have several implementations which are almost complete in terms of functionality, particularly:

1. ArmoryX: We got it working in January of 2013. It was able to do many things: issuing colored coins, installing "color definitions" from web, p2p trade. It had pretty much everything, except it lacked some checks to make it foolproof. We had to abandon it because Armory requires too much RAM and crashes too often, that basically makes it unusable... Also it is hard to get in sync with Armory mainline.

2. WebcoinX: We got a prototype working on testnet in May of 2013. It could do all things Armory could do, I think. But it is too slow to work on mainnet, and it wasn't secure... But wrapping it as a Chrome extension and fetching data in a different way isn't exactly rocket science. Still, we only got progress with bugfixing and GUI, it's still not ready for mainnet.

3. CCoinDemo is a really compact wallet... Basically, it is a thin layer on top of coloredcoinlib which uses web services and bitcoind RPC API. It's something like hundred lines of Python code.

So, there is no shortage of half-assed and mostly-working wallets, there is a shortage of people who will be committed to making a complete, reliable wallet.

I mean, I do what I can... But we could do it faster if we had more people....

(The last guy who fully understood how it works and was willing to write code disappeared in June... I'm talking about Karel Tuma who was leading WebcoinX development. There were do signs that he's going to abandon the project, so I assume that something have happened to him IRL. If not that, we'd probably already have WebcoinX reasonably complete.)

So now about hope: I hope to complete a basic core for NGCCC in a couple of days. I also found several developers interested in working on this. After we have a good core we can work incrementally.

Investors are only interested in things which brings them profit.

It's very hard to extract profit out of fully open source project. It is theoretically possible, but not easy.

Mastercoin was able to get $600k for development through creation of a new currency.

But the whole point of colored coins is that they work directly with Bitcoin and are not limited in any way, so this model cannot be used.

If I understand the coloring algorithm correctly, there has to be a global agreement as to what the colors are.  Otherwise if one party believed in yellow and another didn't (i.e., saw yellow coins as uncolored), they would disagree about how the colors propagated.  Do I have this right?

No, you are mistaken. There has to be agreement between two parties in an exchange as to what the color they are exchanging is. However coloring is deterministic, and does not affect bitcoin consensus in any way. So as long as you and the people you are interacting with are in agreement on the color definition, that is all that is required. You do not need global consensus on anything except the bitcoin block chain.

Here's an updated theoretic model: https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

Colorvalue is a deterministic function. For a given (connected) transaction output and a given color (e.g. "obc:cc8e64cef1a880f5132e73b5a1f52a72565c92afa8ec36c445c635fe37b372fd:0:263370") colorvalue is certain and is same for everyone.

There is, of course, another layer, which we call asset definition layer: people need to know that, say, 10000 atoms of "obc:cc8e64cef1a880f5132e73b5a1f52a72565c92afa8ec36c445c635fe37b372fd:0:263370" means 1 oz of gold backed by issuer ABC.

But this isn't a technical problem. User needs to decide whether he trusts issuer ABC. If he does, getting an authoritative list of colors from issuer ABC is pretty much trivial, for example, one can get them from ABC's web site, and they will be signed with his PGP key.

I see.  I was under the impression that the coloring algorithm in Meni Rosenfeld's paper "Overview of Colored Coins" was the one that's employed.  Thanks.

I don't know whether it would help much but CIYAM Open would be very happy to have the colored coins project listed (fee free for the life of the project).

PM me if you're interested to do that.

Thanks, but we are using a different model now: instead of per-task bounties, we pay according to number of hours spent on work.

As it turned out, it's much easier to hire freelancers than to do this bounty thing... It's now possible to get things done in matter of days, not weeks or months.

Actually we use the same thing, it's just more generalized now, and would allow different algorithms in future.


wat?

the implementation technique has changed quite a few times.  The main concern with Color Coins is performance.  Think NumberTransactions ^ NumberCoinColors.  There haven't been any good studies on how this will pan out but that's the general estimate.  Seems there is a love/hate relationship between core Bitcoin devs and Color Coins, some seem to support it, others don't.  There was the COIN_DUST issue which factors into Color Coin's future.  Putting Color Coins on alt-chain is just pointless because if you have a new chain, you can redesign the tx format completely.  Color Coins main feature is backward compatibility with existing Bitcoin infrastructure.  

Alex has backpeddled a number of times on his statements and I don't spend much time reviewing his claims.  Keep in mind, money has been spent on this project so the investors do have an agenda here.

What we have now in NGCCC is exactly the same thing which I implemented ago (ArmoryX), it is 100% compatible.

We just got better terminology, better understanding how to handle various corner cases, future improvements, better wallet design etc.


Well, the thing is, I'm simply implementing an open source tool for asset tracking on top of Bitcoin blockchain.

I think it's obvious that there are inherent limitations. Say, if BItcoin block size is limited to 1 MB, Bitcoin cannot process more than 7 transactions per second on average. And as each colored coin transaction is a Bitcoin transaction, we cannot have more than 7 colored coin transactions per second either.

So, obviously, it cannot replace NYSE :-), but it doesn't mean that it isn't useful.

For example, existing Bitcoin companies simply do not have trade volumes which would get anywhere close to the limits imposed by the blockchain, so it's quite possible to represent their shares with colored coins and do this decentralized trading thing.

For example, one of the more popular stocks -- AM100 shares on HavelockInvestments -- had just 20 trades in last 6 hours.

So that what I'm doing now: a tool which can be useful in some contexts.

---

Of course, sometimes people ask: what if we need to handle more than 7 transactions per second? Is it possible to do that?

Well, it is possible to do transactions off-chain (i.e. without publishing real Bitcoin transactions), but that requires some trade-offs in decentralization and security.

For example, it is possible to combine colored coins with Open Transactions servers: colored coins will be used to move assets between different servers and long-term wallets, while the bulk of trading will be done within servers.

Sure, it isn't as bulletproof as native colored coins trade, but Open Transactions will be a massive improvement compared to 100% proprietary and opaque platforms like BitFunder, MtGox etc.

In any case, it is important to understand that I'm not trying to sell a complete solution, I'm just developing open source software. It's up to people to decide how to use this software (and whether to use it).

Why would you want to:

 1) implement a complex technology to retrofit to existing Bitcoin

 2) that may have catastrophic capacity issues and introduce a whole new tier of policing problems to Bitcoin

 3) that requires a THIRD or even a FOURTH technology(some of which themselves are unproven or even unspecified) in order to achieve auxiliary functions

Just to do what Confidence Chains does simply, elegantly, efficiently and natively?

Well, what kind of reply do you expect?

It looks like the idea behind Confidence Chains is "Let's just trust some guys to secure transaction processing", and it just isn't something I'm interested working on, sorry.

(Besides that, I believe there are major flaws in Confidence Chains design, but I'm not going to discuss them in this thread as this would be off-topic; and we already discussed them in bitcoinX mailing list anyway.)

---

Another reason for me to work on colored coins specifically is that I don't have enough confidence to work on a completely new cryptocurrency. The good thing about colored coins is that they inherit almost all properties from Bitcoin itself. I like the simplicity of design.

As for capacity issues, I already explained that I do not find them important. When Satoshi released Bitcoin people complained that it won't scale, but look at where Bitcoin is now.

I prefer to do the simple thing first. Is it useful? Yes, it is.

It doesn't solve everything, of course. But I prefer multi-layer design to a monolithic thing which would try to do everything at once. (I don't think that a decentralized replacement for NYSE is even possible, by the way.)

---

I think it's fairly obvious that you're trying to criticize colored coins to promote your Confidence Chains. Well, do you know why people ignore you? Is it some kind of a global conspiracy? No, it's just an obviously bad design.

But the general idea of trust-based consensus is sensible; and if you're interested in things like that, you might be able to cooperate with others and make something good. But to do that you need to be ready to ditch your own ideas and listen to others. I hope you realize that spending all efforts to push the first thing which came to your mind isn't exactly a healthy thing to do sooner rather than later.

(FYI before I started working on colored coins, I was working on an  alt-coin design and on distributed Ripple analog based on merged mining (Ripple.com wasn't public back then). I still believe I had some good ideas, but colored coins just had much higher chances of success, so that's what I focused on.)