Well, it would be quite similar to how mining pools work in terms of centralization. Some pool might be attacked, but that's barely a problem.

Note that thieves wouldn't gain much from a hack, so there is almost no incentive to do that.


I think it's unlikely that full p2p system can be as fast as semi-centralized (federated) one. I.e. daytraders won't like it.

But it would be cool to have it as an option.

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

I feel like a simpler and a bit more centralized solution would offer 95% of joy for 5% of effort. I haven't analyzed it thoroughly, though, so I can be very wrong here... But still, I would prefer seeing something simple up and running to waiting for a perfect solution to be built.

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.

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.

Um, maybe. It depends on how you define "decentralized". But, of course, there is a whole spectrum of solutions from a handful of large providers to full p2p with millions of nodes. (Which I would call 'distributed', maybe.)

Somewhere in the middle there is a federation of order book providers with a significant number of members. I would liken them to mining pool operators (which are numerous), thus it might be "decentralized enough" for Bitcoin crowd's taste.

Full p2p would be cool, but it has numerous problems.


Not quite the same thing: there is much higher barrier to entry for exchange which deal with USD, and also an exchange like MtGox holds people's money, which creates a trust issue.

But I would agree that a solution with completely independent order book providers is far from perfect. But much better than what we have now...

Perhaps a federated protocol won't be too hard to implement...

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

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.

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

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.

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.

We can start with decentralized exchange first. Decentralized means that it lacks single center, not that it is strictly p2p.

For example, there might be three independent operators with their own order books. You can buy/sell via any of them, as security is guaranteed by colored coin protocol, and no matter where you buy, your ownership will be recognized.

If you think all three operators are assholes, you can run your own exchange software: there is almost no barrier for entry. Your exchange will be just as good as any other in terms of security and compatibility. Your only challenge is to attract users to get some market depth.

I believe this means that exchange is fully decentralized. And colored coins are important here because they are the substrate which guarantees security and universal recognition of asset ownership.

Y U NO release a detailed report?

I guess you track NAV using a spreadsheet of some sort, so just releasing that spreadsheet makes a lot of sense.

I think it's important to release it sooner rather than later because you started with non-transparent transfer of assets.

It's great that you post NAV updates, but since we don't know what holdings consist of they might as well be bullshit.

(It's worth noting that contract and communication makes a really good impression, like it's done by a pro. So I'm parking little spare money I have in LTC-ATF.)

USDLTC. But it probably makes sense to calculate price in USD and then convert it to LTC as needed.

So it pays 135 USD per month on average, that would be 1620 USD per year = 0.162 USD per share per year. Buyback is 0.25 USD per share.

So you expect to get 0.25 + x * 0.162 USD where x is number of years until liquidation.

Discounted present value would be something like (0.25+x*0.162)/(1+i)^x where i is interest you might get otherwise.

E.g. x = 3, i =10%:  0.736/1.331 = 0.553 USD.

Current USD/LTC rate on btc-e is 0.046, so we get 0.553/0.046 = 12 LTC breakeven price.

And majority of trade was around that recently...

Replying to 1000 queries per second won't be a problem even for a cheapo box. So I'll emulate 1000 nodes for some time to get reputation and then will attack you.

As markm said, you just have a weird form of proof-of-work which requires CPU power, network bandwidth and IP addresses. But it doesn't make it stronger, it makes it harder to analyze.

With Bitcoin proof-of-work, miners are incentivized to do hashing as fast as possible, so you get no unexpected hacks.

With your proof-of-work an attacker might find some cheaper way to process queries, get some cheap bandwidth and IP addresses. (For example, he might be an ISP himself.) Other nodes do not have an incentive to do things in an optimal way, so you don't know how much attack costs.

Attack on bitcoin is estimate to cost millions of dollars. Attack on qubics might cost thousands of bucks. Or perhaps it would be essentially free for organizations who have access to resources. (Providers always have some spare capacity which isn't used for anything else.)

Shameless self-plug: I'm working on implementation, it is called "colored bitcoin": https://bitcointalk.org/index.php?topic=106373.0

Perhaps I have missed something... What traffic?

I think it's better when trading platform is separate from verification/insurance/rating stuff.

When exchange is separate from these things you have a separate market for verification/insurance/ratings. Market means competition. So if one rating agency fucks up, another will replace it.

But if it is done for everybody by exchange, there is no big incentive for an exchange to offer best services because it already has monopolist position by being an exchange.

Also, insurance always cuts from profit, and so it should be investors/issuer's choice whether to use insurance. Again, if exchange enforces that, it would be like bundling a service nobody wants.

The idea with keeping collateral is simply bullshit. If 10% of money is reserved for compensation in case of failure, it would be just easier for investors to invest 90% of money they wanted to invest and keep 10% in their wallets. It's the safest.

Insurance implies existence of insurance pool. Which means that successful companies will subsidize failed ones. Do I need to explain why not everybody wants this?

It would be cool if equipment, land and other property could be used as collateral, but realistically that would require lawyers.

You can buy from whoever sell them on market, just not from the issuer.

Note that it's good idea to get info on pricing before you buy.

Essentially this bond is going to pay us about 4 LTC per share on average. After some time it would be bought back at 6.4 LTC.

If you think it will exist forever and you want to a return of 10% per year, the breakeven price is about 4/0.1 = 40. If it's cheaper than that, buy!

However "forever" might be too long. Let's consider a situation where bond will pay coupon for 3 years and then it will be bought back. Then you'll get 4*3+6.4  = 18.4 LTC.

However, if you invest your money at 10% per year, you would get 1.33 of your original investment in 3 years.

So breakeven price is 18.4/1.33 = 13.5. Before you take risk into account...

So I'd say that people who bought it at @20 are kinda too optimistic...