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

[killerstorm]

i'm actually working on a solution for this now. there shouldn't be any issue with the buyers, but ANY sellers would in fact have to maintain some form of hot wallet in order to automate the process.

In p2ptrade protocol, there is no inherent difference between sellers and buyers. Alice announces her offer, Bob then sees her offer and proposes an exchange. Alice might offer with uncolored Bitcoins in exchange for USDcoins, or USDcoins in exchange for uncolored Bitcoins.

If Alice is a market maker of sorts, wanting to perform many trades per day, aiming to earn bid-ask spread, she needs coins in her wallet.

BUT it isn't same as an exchange keeping coins in their hot wallet.

One of major difference is that colored coins allow you to use Hollywood principle: "don't call us, we'll call you".

Basically, your trading machine can be behind a firewall. Or even two firewalls.

You only need to poll p2ptrade order book server from time to time. So you only need to secure HTTP client software and software which processes p2ptrade messages.

This is a very small surface for attack. If you're paranoid, you can implement handler for these protocols in a very defensive style, using programming languages which are regarded as secure (Ada, Haskell, ML...), maybe even use formal verification.

If you follow all security protocols... In order to penetrate through this, attacker will have to penetrate through your firewall(s), then penetrate through security of operating system which has no open ports... Well, good luck with that.

There is a second degree of defense... Let's say you're a market maker and you have 10000 USDcoins and 100 BTC. However, maximum order you're willing to process is 100 USD/1 BTC, and you keep only 1000 USD/10 BTC in your hot wallet.

When hot wallet is exhausted, you receive a notification. Then you can get a log from trading system, get it on flash drive to your secure, air-gaped computer. Analyze log and refill hot wallet as necessary. Then move refilling transactions to trading system...

So basically you keep majority of funds in your secure, air-gaped, encrypted system which might require all kinds of authorization (password, fingerprint scan).

Even if attacker will penetrate through first line defense (which is next to impossible if it is done properly), he only gets 10% of funds.


There is, however, an alternative to this: slow order processing. Market maker might announce his offers and log off. Then log on hour later and process these orders. Potentially, manually...

This requires some changes to protocol, and some reputation system. But it is definitely doable.

[1715307183]

1715307183

[1715307183]

1715307183

[1715307183]

1715307183

[nyusternie]

There is, however, an alternative to this: slow order processing. Market maker might announce his offers and log off. Then log on hour later and process these orders. Potentially, manually...

This requires some changes to protocol, and some reputation system. But it is definitely doable.

i'm not so concerned about the market makers; they should be more than well equipped with the proper security to operate their automated trades. the bitcoin-savvy should also be fine. its the n00bs that i'm really trying to support. bitcoin is just too goddam hard to use for >90%.

i really believe a manual system could work fine, but not for the masses. when it comes to bitcoin (and the other alt-coins), good security + user-friendliness (seems to) = mission impossible. i've recently started looking into ripple (seems to offer a lot of options unavailable with bitcoin), but i've got to spend more time with it

a decentralized reputation system would be fantastic.
came across this a while ago. a step in the right direction
https://bitcointalk.org/index.php?topic=149385

[dansmith]

I started a thread which aims to pool knowledge surrounding the legal side of being a colored-coin emitting business.

https://bitcointalk.org/index.php?topic=176575.0

I feel that issuing colored coins may be considered on par with issuing an in-game currency and may not be subject to strict financial regulations.

[dansmith]

Today it dawned upon me those who use smartcoins are immune to the often-heard question "what is the internet gets shut down".
If it gets shut down, the owner of the smartcoin can prove to the smartcoin issuer that he is indeed an owner by providing his privatekey to the address which last held the smartcoins when the internet got shut down. This way he can redeem his  USDcoins or Goldcoins back to USD/gold.

Ain't that sweet?

[dansmith]

I propose that we as developers create a library on top of bitcoind which would allow existing exchanges to integrate colored coins (CC).
I submit that it is the day traders who stand to gain the most from CC at this point in time. With CC, traders can jump on any CC-friendly exchange, without worrying about moving fiat between exchanges.

This library will have all the primitive functions needed to analyze the blockchain.
Actually the only two primitive functions I can think of is "determine if a certain output is colored or not" and maintain cache of transactions for a certain color to avoid re-scanning the whole blockchain.

I think that could be a good start.

Any other thoughts? What other primitive functions would an exchange need to easily integrate CC?

[killerstorm]

Can't you just use ArmoryX for that? It can be run as a server, without GUI.

[dansmith]

Trying to understand ArmoryX code, I came across:
https://github.com/bitcoinx/BitcoinArmory/commit/791e3e0d88e15b7d48590f12da8324ebaa5c2854#L0R3677
with a comment:
 //transaction is invalid if sum(inputs) > sum(outputs)

I always thought sum(inputs) > sum(outputs) makes a perfectly valid transaction. What am I missing?

[killerstorm]

Trying to understand ArmoryX code, I came across:
https://github.com/bitcoinx/BitcoinArmory/commit/791e3e0d88e15b7d48590f12da8324ebaa5c2854#L0R3677
with a comment:
 //transaction is invalid if sum(inputs) > sum(outputs)

I always thought sum(inputs) > sum(outputs) makes a perfectly valid transaction. What am I missing?

Sorry, that's just a typo. Comment should be: sum(inputs) < sum(outputs).

[dansmith]

killerstorm, the following sentence goes over my head, could you please paraphrase it, so that an uninitiated person like myself could understand:
(taken from https://github.com/killerstorm/colored-coin-tools/blob/master/colors.md )

Formal definition:

Preceding sum of input i is sum of values of all outputs from 0 below i.

The way I read it:
"Preceding sum of input i" - hmm, an input just has a value, what sum are we talking here about?

[dansmith]

OK, so maybe

Preceding sum of input i is sum of values of all outputs from 0 below i.

should read:

Preceding sum of input i is sum of values of all INPUTS from 0 below i.

I understand that you were writing the spec in a hurry. Because you know what you were talking about. But for me it is a frustrating experience having to read a sentence many times over without it making sense.

[dansmith]

I need some help understanding BitcoinX protocol:

Let's say in the future there will be 1000s of colored coins floating around. So a p2p exchange has to know all the 1000s colors and has to scan the blockchain for each color, is that correct?

Because (according to the spec) a transaction involving multiple colored coins has to have all its inputs sorted by color. And so, the colored coins-aware software has to know all colors in advance in order to parse such a multi-color transaction.

Is this observation correct or am I missing something?

[dansmith]

Quoting myself:

Let's say in the future there will be 1000s of colored coins floating around. So a p2p exchange has to know all the 1000s colors and has to scan the blockchain for each color, is that correct?

Upon some consideration, the answer is:
No, you don't have to know every color in existence to trace a certain color through the blockchain. Which is great!

[killerstorm]

I understand that you were writing the spec in a hurry. Because you know what you were talking about. But for me it is a frustrating experience having to read a sentence many times over without it making sense.

Yeah, sorry. I thought somebody will make a pull request...

Because (according to the spec) a transaction involving multiple colored coins has to have all its inputs sorted by color.

Where have you got it from? It is a recommendation, not a requirement.

Let's say in the future there will be 1000s of colored coins floating around. So a p2p exchange has to know all the 1000s colors and has to scan the blockchain for each color, is that correct?

No, you don't have to know every color in existence to trace a certain color through the blockchain. Which is great!

Yup, this was a design consideration. People are now working on a color server, by the way.

And we have a thin client which kinda works, but has problems with performance.

While we are at it, if all genesis tx outs are somehow marked in a blockchain, it is possible to make a very fast and simple server which knows about all colors in existence. It can easily scale to millions or even billions of colors without a problem.

Sadly, marking genesis tx outs seems to be too much of a requirement... So we'll probably end up with two server designs, "fast" and "slow".

Oh, BTW, as you're reading spects... There is an upcoming change to how multiple issues will work:

Each issue (i.e. a genesis tx out) is a separate color which does not mix with other colors, but an asset can consist of several colors.

This change eliminates a number of complexities. Basically it is much more straightforward and secure. It also enables us to create faster color-aware servers and clients and enables multi-issuer assets.

[dansmith]

killerstorm, it's good you are making headway.
I want to contribute some code as soon as I have all the fundamentals figured out.

The spec I mentioned is:
https://github.com/killerstorm/colored-coin-tools/blob/master/colors.md
which says:

All inputs and outputs should be sorted by color, with matching sort order. E.g. red inputs, blue inputs, uncolored inputs. Red outputs, blue outputs, uncolored outputs.

This lead me to believe there was a "sort order", like ascending sorting by color ID or something.
Now I realize there need not be any order, only that same colors should be adjacent (next to each other).

Each issue (i.e. a genesis tx out) is a separate color which does not mix with other colors, but an asset can consist of several colors.

So, as I understand it, you are saying that each genesis tx out  will be considered a separate color. By "does not mix with other colors" you mean that different colors of the same asset will not be lumped together?

[killerstorm]

All inputs and outputs should be sorted by color, with matching sort order. E.g. red inputs, blue inputs, uncolored inputs. Red outputs, blue outputs, uncolored outputs.

This lead me to believe there was a "sort order", like ascending sorting by color ID or something.
Now I realize there need not be any order, only that same colors should be adjacent (next to each other).

This rule is basically a recommendation on how to create transaction, it serves for illustrative purpose, but it's now how you're supposed to identify colors.

When client tries to identify color of a transaction output, it should follow the scheme described in "Order-based coloring" section, which means:

1. Color of each output can be found independently, they do not affect each other in any way.
2. Software MUST NOT try to validate transaction's coloring in any way.

So, as I understand it, you are saying that each genesis tx out  will be considered a separate color. By "does not mix with other colors" you mean that different colors of the same asset will not be lumped together?

Yes.

Some transactions might get larger because of this, but I think it's more important to have a reliable, working system than to optimize encoding.

[BTConomist]

Isn't it possible to color any coin in the blockchain? Does it have to include the Genesis block only?

[killerstorm]

Isn't it possible to color any coin in the blockchain? Does it have to include the Genesis block only?

Yes, it is possible to color any coin. We talk about "color genesis", not about genesis block. It is just an analogy: just as a genesis block is a start of a blockchain, "genesis transaction output" is a start of a new color.

[really]

太牛逼了，向楼主致敬。

It's amazing！The salute to the landlord.

[killerstorm]

By the way, people, this ArmoryX thing is outdated: basically, Bitcoin Armory just isn't a good platform.

We are working on "next-generation colored coin client" which will work without Armory. It will be available in about a month:

https://github.com/bitcoinx/colored-coin-tools/wiki/The-next-gen-colored-coin-client

Currently there is a very basic tech demo in Python: https://github.com/bitcoinx/ccoin-agent-py

Also we are working on WebcoinX web client: http://bitcoinx.github.io/webcoinx/

[michaelmclees]

Is the new client ready?