ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/..

[LurbQBurdock]

Hi killerstorm and the rest of the colored coin team:

I have a particular application in mind for assets backed by cryptocurrencies.  So far, using colored coins seems to be my best bet, but I'm wondering if certain things are possible:

1.  Can an issuer color coins that don't belong to him?  For instance, I sell 1 satoshi colored as a "Lump of Coal"  Now, later, the person who owns the lump of coal contacts me and we decide that the lump of coal should be on fire.  I'd like to be able to add the color "Burning Coal" to the satoshi even though I don't own it (or perhaps the owner could color it.  but it needs my signature on it).  It would be very inconvenient for the other person to have to return the coal to me in order for me to light it on fire.

2.  How long can a moniker be, and do I need to worry about spamming the blockchain if I make 10,000 different colors?  For instance, it might be useful to me if I could write a lot of details about this particular piece of coal on it, but that might be a 300 character long moniker, and it might potentially mean a separate color for each and every of the 10,000 different pieces of coal in my application.  (Of course, this destroys fungibility, so it would make setting up an exchange very difficult.  But in principle, I might still want to do something like this)

3.  Is it possible for me to determine the order that colors were added to a satoshi?  For instance, if we later add the color "Burnt Coal" to the example satoshi, it now has 3 different colors "Lump of Coal", "Burning Coal", "Burnt Coal".  I need to know that "Burnt Coal" is a newer color than the other 2.

Additionally, bitcoin's transaction fee is currently way too expensive for my application.  I can't justify selling pieces of coal that only have uses inside my application at 0.0001 btc each when the transaction fee is another 0.0001 btc.  This would be easily fixed by my using a cryptocurrency with a cheaper fee.  Are there any plans to develop a version of ChromaWallet that can work with other cryptocurrencies?

Thanks for your time

[1714981916]

1714981916

[1714981916]

1714981916

[1714981916]

1714981916

[1714981916]

1714981916

[killerstorm]

So far, using colored coins seems to be my best bet, but I'm wondering if certain things are possible:

It's worth noting that colored coins concept is fairly general, it can be customized for a specific application.

It's not just "what chromawallet can do". ChromaWallet is just one of applications.

1.  Can an issuer color coins that don't belong to him?

Yes. Color exists only as a client-side configuration, so you can just add a new definition.

(This isn't true for all implementations of colored coins, say, BitcoinX specification requires a particular format of a genesis transaction. But chromawallet/chromatoken implementation is very flexible.)

It would be very inconvenient for the other person to have to return the coal to me in order for me to light it on fire.

Well, that can be implemented as a special kind of transaction, similar to how p2ptrade works. But you gotta pay a fee for that. If you're talking about cheap-ass assets, it's better to avoid fees...

2.  How long can a moniker be,

Monikers exist only on client simply for convenience. They can be arbitrarily long, but you probably want a custom asset definition format, there is no need to stuff all the information into the moniker.

and do I need to worry about spamming the blockchain if I make 10,000 different colors?

Each particular colored coin is a separate transaction output. 10000 doesn't sound like a large number...

and it might potentially mean a separate color for each and every of the 10,000 different pieces of coal in my application.

People usually call this approach (separate color for each individual thing) it 'smart property' or 'transferable virtual property'. See here: https://en.bitcoin.it/wiki/Contracts

3.  Is it possible for me to determine the order that colors were added to a satoshi?

Depends on how you introduce these colors...

Additionally, bitcoin's transaction fee is currently way too expensive for my application.  I can't justify selling pieces of coal that only have uses inside my application at 0.0001 btc each when the transaction fee is another 0.0001 btc.  This would be easily fixed by my using a cryptocurrency with a cheaper fee.  Are there any plans to develop a version of ChromaWallet that can work with other cryptocurrencies?

Yes, but you should consider other options, like something not based on blockchains... OpenTransactions, maybe?

You'll have to run your own server,  but transactions can be free, I think. I have no idea how hard is it to customize it, though.

[overcoin]

I'm still trying to find out the optimum coloring scheme for my Gold Backed Bitcoin project. Currently ChromaWallet supports only order-based coloring scheme. Will you also add support for tagging-based or per-satoshi coloring?

[abuelau]

So, when are we going to have a lightweight version of the wallet? If it requires Bitcoin-qt it will be a big challenge to get users to use it.

[EskimoBob]

How do you "import" and reissue a security that was previously issued in one of those closed exchanges like btct.co etc?

[killerstorm]

Just in case, what is available now is a preview, alpha version, meant only to run on the testnet.

It's still possible that we'll change some substantial aspect, I don't want to be tied to this old release.

Will you also add support for tagging-based or per-satoshi coloring?

Yes. In fact we already implemented some form of tagging:

https://github.com/bitcoinx/ngcccbase/issues/27#issuecomment-29735370

but it's less than perfect...

I have some improvements in mind which could make it satisfactory, but I'm waiting for comments from Vitalik Buterin who writes "BitcoinX whitepaper": ideally we would use same kind of coloring scheme in BitcoinX and chromatoken versions.

Also I'd like to get comments from Peter Todd (bitfield-tagged color kernel mentioned above is based on his ideas). He now works for Mastercoin, but I don't know whether that preclude him from helping us with coloring schemes.

In simple terms, I know a way to make both padding and scaling parametrizable on transaction level, which will let us to achieve nearly-optimal satoshi efficiency. Also transactions will have unique signature, which is important for backward-scan traversal strategy.

I'm not sure whether we should use nSequence or OP_RETURN. nSequence is more efficient, but seems kinda hackish.

Also any scheme with padding or scaling creates some accounting problems, but we can probably take them into account in p2ptrade with some effort.


We won't implement per-satoshi tracking. I actually implemented it for a different project (twice!), but I'm not going to add it to coloredcoinlib because it's not compatible with thin clients (if colored satoshi can be paid as a fee), and hard to deal with anyway.

[killerstorm]

So, when are we going to have a lightweight version of the wallet? If it requires Bitcoin-qt it will be a big challenge to get users to use it.

Indeed. We plan to include this option (run without local bitcoind) into the beta release. (Probably in January.)

We have already implemented a very basic version of backward scan in coloredcoinlib: https://github.com/bitcoinx/ngcccbase/blob/master/coloredcoinlib/colordata.py#L76

But it needs some improvements... Also it isn't recommended for use with OBC.

[killerstorm]

How do you "import" and reissue a security that was previously issued in one of those closed exchanges like btct.co etc?

We'll probably write some kind of script for that when software will be ready to run on mainnet (I hope in January) and IF there is interest in this.

I think it can be some kind of a web site where user enters his colored coin address, signed with his public address on btct.co. Then once a list of colored coin addresses are obtained, script will send them colored coins according to data from btct.co.

[Peter Todd]

Also I'd like to get comments from Peter Todd (bitfield-tagged color kernel mentioned above is based on his ideas). He now works for Mastercoin, but I don't know whether that preclude him from helping us with coloring schemes.

In simple terms, I know a way to make both padding and scaling parametrizable on transaction level, which will let us to achieve nearly-optimal satoshi efficiency. Also transactions will have unique signature, which is important for backward-scan traversal strategy.

I'm not sure whether we should use nSequence or OP_RETURN. nSequence is more efficient, but seems kinda hackish.

So the big tl;dr with nSequence vs any other scheme is that only nSequence is based on per-txin-scriptSig information, or basically it's the only scheme(1) that's CoinJoin-compatible. The reason why it's compatible is that all the information about where the "color" of the txin is meant to go is in the txin, rather than any other part of the transaction, which allows the rest of the transaction to be specified by other individuals.

I'm rather inclined to keep that feature simply because being able to easily hide who paid for a given colored coin is useful privacy, and increases the anonymity set for everyone else.

1) You can use the R-value nonce in the ECC signature too, but... ugh. Though it would have the advantage of making colored coin transactions completely indistinguishable from regular ones.

[killerstorm]

So the big tl;dr with nSequence vs any other scheme is that only nSequence is based on per-txin-scriptSig information, or basically it's the only scheme(1) that's CoinJoin-compatible. The reason why it's compatible is that all the information about where the "color" of the txin is meant to go is in the txin, rather than any other part of the transaction, which allows the rest of the transaction to be specified by other individuals.

I'm not sure whether you mean that it is compatible with a particular existing protocol, or whether it is compatible with p2p coin mixing in general.

I believe that 1) we need to use color-aware p2p coin mixing for colored coins; 2) in that case it doesn't matter which coloring scheme you use.

First, I should note that I did research on p2p mixing before it was cool about a year before gmaxwell described CoinJoin, so I don't know what terminology is currently in use... But anyway, I describe quality of mixing in terms of entropy, i.e. a measure of uncertainty. E.g. if attacker is able to trace a particular txout to a set of 1024 txouts, each of which can be a source of money equiprobably, then mixing entropy is 10 bits. Bigger is better.

Suppose there are colored coins in a CoinJoin transaction, for simplicity we can assume that there is one txin/txout with each color. Obviously, attacker can trivially connect txout to txin. So we get two things out of it:

1. there are no mixing entropy gains for colored coins
2. mixing entropy gains are reduced for non-colored coins

So it is definitely better when mixing is color-aware... And if mixing is color-aware, then order-based coloring and its variants work fine. Basically, you just do this mixing thing for each color in separation (it's OK to reorder txins/txouts withing one color), and then you just concatenate smaller transactions together (txins_1 + txins_2 + txins_3, txouts_1 + txouts_2 + txouts_3).

So now

1. it is possible to mix colored coins too
2. everybody can easily understand entropy gain and plan accordingly.

Perhaps I'm missing something... If your point is that it is possible to re-use existing protocol (if it is possible, I'm not sure about that: we need an ability to modify nSequence after list of outputs is known), then I guess it is good because it is saves work, but doing color-aware mixing protocol is definitely better in the long term.

being able to easily hide who paid for a given colored coin is useful privacy, and increases the anonymity set for everyone else.

You can get same results by mixing your coins before you buy that colored coin.

[FrictionlessCoin]

I have a query.  What would it take for a merged mined coin like iXcoin to support colored coins 'natively'.

In other words,  iXcoin has less of the legacy baggage that bitcoin has, so it is within the realm of practical that iXcoin be modified to support colored coins natively.

What would be the features to accomplish this?

Note: iXcoin is merged mine with BTC, so it has around 40% of the network hash rate as BTC.  In fact iXcoin has a surprising 5 peta hash per second network.   It is at least one order of magnitude more secure than say PPC.

[fgbnbb]

Here is  "[ColoredCoins]Pre-Launch sale Announcement".
https://bitcointalk.org/index.php?topic=402561.0
Is it a scam???

[sixteendigits]

Here is  "[ColoredCoins]Pre-Launch sale Announcement".
https://bitcointalk.org/index.php?topic=402561.0
Is it a scam???

Bump

This is what I came here to ask.

[BitThink]

It is absolutely a scam.

[funkymunky]

I've reported it to the Mods, I suggest you all do the same please.

Looks like someone already fell for it?
https://blockchain.info/address/1CwDJyAJTUkwpmmU3sfBmVY41bmkKPuoC

[killerstorm]

Colored coins is a concept, it is not a concrete coin one can buy.

I have no sympathy for person who fell for it, scam announcement didn't even try to explain how it could make one rich.

[Woaibit]

Colored coins is a concept, it is not a concrete coin one can buy.

I have no sympathy for person who fell for it, scam announcement didn't even try to explain how it can make one rich.

I can't agree more. Let's keep moving where we are at.

[killerstorm]

I have a query.  What would it take for a merged mined coin like iXcoin to support colored coins 'natively'.

Well, you need a developer who can do that kind of thing...

From technical perspective, the solution is kinda obvious: add color tags to transaction outputs, track "colorvalue" for each UTXO, make sure that miners check validity, introduce a way to make genesis transactions... That's the basic version.

Freimarkets is quite a bit more sophisticated, but I guess you're asking about the simplest thing which could work, right?

If you can find a good developer (ideally, one who is already familiar with Bitcoin source code), it would take him something like a week to implement a basic version.

There are many design considerations, say, compatibility with existing tools... Is that important? Hard to say.

[FrictionlessCoin]

I have a query.  What would it take for a merged mined coin like iXcoin to support colored coins 'natively'.

Well, you need a developer who can do that kind of thing...

From technical perspective, the solution is kinda obvious: add color tags to transaction outputs, track "colorvalue" for each UTXO, make sure that miners check validity, introduce a way to make genesis transactions... That's the basic version.

Freimarkets is quite a bit more sophisticated, but I guess you're asking about the simplest thing which could work, right?

If you can find a good developer (ideally, one who is already familiar with Bitcoin source code), it would take him something like a week to implement a basic version.

There are many design considerations, say, compatibility with existing tools... Is that important? Hard to say.

Would you be able to come up with a more detailed spec? 

Alternative,  would you be able to act on an advisory role on the implementation?  Just review and validate the implementation?

[killerstorm]

Would you be able to come up with a more detailed spec?

No.

Alternative,  would you be able to act on an advisory role on the implementation?  Just review and validate the implementation?

Yes, if you can find people who can implement it (first and foremost brave C++ programmer(s)), I'll be able to discuss it.