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

[Mike Hearn]

It seems likely that people will hook up bots to distributed bonds as soon as they pop into existence.

Why? What would such a bot do? I know HFT bots exist on regular stock and currency exchange markets but they are exploiting very specific issues. Debt issued on a P2P bond market still has to be issued for some kind of purpose and under some kind of identity so you can have confidence you'll get it back.

If I think about the kind of economies we see today in bitcoin-land, I'd expect a P2P bond market to be used at the same kind of volumes as GLBSE was. I don't recall reading about bots operating on GLBSE. What algorithms would they use that require HFT?

[killerstorm]

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

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

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

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

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

[markm]

Where are people getting all these bots?

I am curious because despite seeing sometimes some quite large and long lasting arbitrage opportunities no bots seem to be closing the opportunities. Also it would actually be useful for things like when someone offers to sell asset X for asset Y and someone offers to sell asset Y for asset X, because although some fortuitous choices of scale and price can sometimes make obvious matches across the two markets often it is rather beyond what generic order-matching could reasonably be expected to handle.

For example if I offer on the hundred-scale market to sell fifty lots of a hundred asset X at 3 asset Y per hundred and meanwhile someone offers on the single unit scale to sell three individual units of asset Y at 33 asset X each, there is a profit of 1 unit of asset X to be made by cross-market matching between the X/Y scale 100 market and the Y/X scale 1 market...

-MarkM-

[jl2012]

You understand nothing.

A meltmining laundry can melt a small number of coins every block it finds.

¿You say you can adapt your taint software to find the unusual fee transactions?

Ok, I say that I will send 2 to 5 tainted BTC fees in the next block and wait to be mined by p2pool or Deepbit.

¿What do you think will the miners do when they start getting their accounts freezed in MtGox because your taint lists and software? They can't dodge the tainted melting coins fake transaction I made and they can't prove they aren't the melting launderers.

So the tainted coins list/software adoption is the beginning of the end of bitcoin.

The colored coin algorithms do not violate any part of the bitcoin protocol. Instead, it is exactly how bitcoin works: you can trace every satoshi back to its generation to make sure there is no counterfeit. The untraceability of bitcoin is just your fantasy. If you believe this is the end of bitcoin, you don't understand bitcoin at all and you should sell.

Back to genius melting pool. You cannot broadcast your melting transactions as usual. You have to mine your own block to include them. These "hidden transaction" could be spotted out by monitoring the network. If there are lots of such transactions, that would looks suspicious. The difference between a legitimate miner and a laundering miner is: those hidden transactions will never go to a legitimate miner.

Also, to launder merely 1BTC (which is basically nothing in the world of money laundering), you need 200 transactions. With only 144 blocks each day, how many TH/s do you have?

You mention TOR. Yes, a much easier way is to launder through SR.

[killerstorm]

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

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

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

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

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

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

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

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

[jgarzik]

It seems likely that people will hook up bots to distributed bonds as soon as they pop into existence.

Why? What would such a bot do?

That is the open and operative question.  GLBSE had bots, bidding and asking.  It seems reasonable to assume that any P2P solution would quickly see the same, right out of the gate.

[justusranvier]

Why? What would such a bot do? I know HFT bots exist on regular stock and currency exchange markets but they are exploiting very specific issues. Debt issued on a P2P bond market still has to be issued for some kind of purpose and under some kind of identity so you can have confidence you'll get it back.

HFT bots exist on regular stock and currency exchanges because they are allowed by the exchange to cheat. Exchanges are able to get away with this because there is a high barrier to entry that keep more honest competators out of the market.

[markm]

Heh nice point about HST, but yet I don't think people are ready yet for a more thorough full processing of every order.

I had figured in doing bids by email, possibly even as slow as each day but maybe faster, maybe even every hour or half hour, every quarter-hour might be too fast.

Basically get up in the morning, look at what orders were placed yesterday but not filled, compare to the prices of the orders that were filled to come up with what seems like a sensible offer to place today, place your offer and get on with your day kind of thing.

Receiving the newspaper's stock-market prices/offers/etc report every half hour might be way too much email-spam.

-MarkM-

[guruvan]

It seems likely that people will hook up bots to distributed bonds as soon as they pop into existence.

Why? What would such a bot do?

That is the open and operative question.  GLBSE had bots, bidding and asking.  It seems reasonable to assume that any P2P solution would quickly see the same, right out of the gate.

All kinds of bots As soon as there's something to buy, someone will buy it in the hopes someone will buy it on pure speculation & to start price discovery. Because it's a 24/7 market, active traders and investors will want to fire up bots to watch while they're asleep (at least) Bots don't need to engage in HFT to be effective.

As there's more to invest in, bots will produce lists of available securities, ratings, issuers, and all kinds of analytic data.

The most logical bot to see would be an Exchange Agent 

[yoniassia]

The bitcoin community is so technical savvy, there will be more bots than humans

[allten]

There's so many threads and related topics to this stuff.

It is really fascinating and a huge step in the right direction IMO.

I want to throw a bounty out there for 2 BTC. Feel free to link to this post.

What is the bounty for? It's for a finalized protocol specification and description
of the entire colored coin and closely related concepts. It can be in the form of a wiki (I personally
prefer a PDF download). In order to claim my bounty, the spec' needs to become the primary
reference.

Those that have run off and started coding already are doing a great service of
verifying the concept in computer programming language, but at the same time are putting
the cart before the horse if they don't take the time to "hash" out the overall protocol
specification IMO.

Thanks to all your efforts.

[killerstorm]

There are many open questions now:

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

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

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

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

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

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

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

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

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

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

[killerstorm]

Current state of "proof-of-concept":

I'm working on adding colored coin support to Armory, order-based style. Coloring itself is like 95% complete.

Colors also need to be supported in wallets and in GUI. I don't really know how to do it "right", but I have a good plan for half-assed implementation

By half-assed I mean there will be a button to switch current color.

I've chosen Armory because I think it would be easier to implement advanced features (exchange, coin swap etc.) in Armory. Also coloring implementation might be a bit easier because Armory scans whole blockchain at start anyway, so there is no need to persist color information.

[jgarzik]

A couple pybond implementation notes:

1) pybond will add a "<BOND+hash><OP_DROP>" for tracking purposes, so I'm not doing much in terms of color tracking for now.

2) pybond / smartcoin will use two RPC endpoints:  one for smartcoins (colored coins), and one for bitcoin payments.  Thus, two wallets.  This seems safer than mixing smartcoins and regular bitcoins.  This "firewall" prevents any client from accidentally spending the wrong coins.

[killerstorm]

1) pybond will add a "<BOND+hash><OP_DROP>" for tracking purposes, so I'm not doing much in terms of color tracking for now.

1. But it's not standard transaction yet?
2. You still need to verify that this output can be tracked down to 'genesis' output, otherwise anybody can fake it.
3. If output's value represents how many bonds one owns, tracking it down isn't completely trivial.

2) pybond / smartcoin will use two RPC endpoints:  one for smartcoins (colored coins), and one for bitcoin payments.  Thus, two wallets.  This seems safer than mixing smartcoins and regular bitcoins.  This "firewall" prevents any client from accidentally spending the wrong coins.

If you're going to pay txn fees you need access to two wallets at once...

[jgarzik]

1) pybond will add a "<BOND+hash><OP_DROP>" for tracking purposes, so I'm not doing much in terms of color tracking for now.

1. But it's not standard transaction yet?

Correct.  A small bit of transaction metadata has been proposed, however:  https://github.com/bitcoin/bitcoin/pull/1809

This has the disadvantage of not being a standard transaction right now, and additional chain bloat.  But it is very useful to atomically attach a signed hash (metadata) to the transaction.  It is potentially more reliable than entirely depending on an external entity to assign meaning to the smartcoin/bond.  And it makes third party verification of bond holder claimers more reliable, as bond activity is easier to publicly track.

A purely colored coin solution does not have any external linkages.  This has the advantage of being a standard transaction right now, and does not carry metadata that might be accidentally or maliciously corrupted/lost.  The disadvantage is you miss any value obtained by atomically attaching signed metadata to the transaction.

2. You still need to verify that this output can be tracked down to 'genesis' output, otherwise anybody can fake it.

Correct.  It is in the bond issuers interests to accurately track this -- they do not want to pay interest to everybody who inserts a "BONDHASH<abcd1234>" into the blockchain ;-)

3. If output's value represents how many bonds one owns, tracking it down isn't completely trivial.

Correct.

2) pybond / smartcoin will use two RPC endpoints:  one for smartcoins (colored coins), and one for bitcoin payments.  Thus, two wallets.  This seems safer than mixing smartcoins and regular bitcoins.  This "firewall" prevents any client from accidentally spending the wrong coins.

If you're going to pay txn fees you need access to two wallets at once...

This is true, and it will typically be agreed beforehand who is paying fees.  An atomic coin swap involves two parties, but only one will likely pay fees.  If it is the smartcoin transferee, they will need to keep some small change for fees, yes.

[matthewh3]

As long as the shareholders don't massively disagree I'm going to offer out a 0.5% ownership of the former GLBSE mining stock/asset RSM - (https://bitcointalk.org/index.php?topic=63257.0) - That works out currently as ownership of 0.9(GH/s) of BFL-SC-Singles although we will be saving 50% of profits towards buying more ASIC's to increase the (MH/s) per share ratio.  For you to implement this idea and maintain it.  You wont receive the coloured coins relating to that 0.5% that will be held in a separate account managed by me but you will receive all profits made from 0.5% ownership as long as you maintain the code.  I've also offered this bounty to this coloured coins project too - (https://bitcointalk.org/index.php?topic=117630.0) - so the first/best implementation will win the bounty.  We don't need to use the coloured coins for about another month yet when we receive our first BFL-SC-Single.

[Red Emerald]

If this is built on top of Bitcoin, could the transaction fee rules get in the way? I'm not sure, I'm just wondering, and I've had a couple beers.

In the interest of exploring new ideas, would this work better as an alt-coin that can be merged mined with bitcoin?  Then we can experiment with custom generation methods and maybe even some custom opcodes.

With cross-chain trading we can still sell assetcoins (just a placeholder name to ease the discussion) for bitcoin, but with it being it's own coin, we could also change the generation method.  Maybe with this alt-coin, mining would have no reward and there wouldn't be transactional fees.  Instead, we could have a custom transaction that could make coins out of nothing. Since this would be merge-mined with bitcoin the generation wouldn't be a problem (miners are still being compensated).  However not having transactional fees would be an issue.  We dont want someone spamming, so maybe an alt-coin wouldn't work.

I still think having a minimum of one satoshi per share is a problem.  The shares themselves should have no value besides that of the company.  What if the value of Bitcoin goes up and your shares are now worth more used as bitcoin then traded as assetcoins? Maybe an alt-coin would cause more problems than its worth just to solve this one, but I'm just throwing out ideas.

As far as HFT goes, what if the client itself is essentially a trading bot?  Trades would only happen while you are online, but this could remove some of the problems with needing a centralized order book.


For example, I want to start a company with 1000 shares, so I send a special transaction that says "Give me 1000 assetcoins for X company with signed contract hash Y."  After a few confirmations, I would make a standing order in my client to sell those shares for .1BTC each (just an example number). Anyone could look up my contract out of band and make sure the hash matches so they know they are paying the right person.  Then they would open their client and start a cross chain transaction with me.

[killerstorm]

If this is built on top of Bitcoin, could the transaction fee rules get in the way?

Yes. But it depends on what you're doing. For many uses fees are OK.

In the interest of exploring new ideas, would this work better as an alt-coin that can be merged mined with bitcoin?  Then we can experiment with custom generation methods and maybe even some custom opcodes.

No. If it is built on top of Bitcoin it means that we can buy colored coins for Bitcoins in a secure fashion. It is a great feature to have.

Also I don't think any custom generation methods or opcodes. Stuff we have now is enough to implement colored coins.

But perhaps alt-chain specifically for colored coins would be useful for something... It isn't like we need to choose one or another: we can have both.

With cross-chain trading

I don't think it works: since it's not atomic, it is prone either to double-spend attacks or DoS attacks where attacker would bury both his and your coins.

Since this would be merge-mined with bitcoin the generation wouldn't be a problem (miners are still being compensated).

Mining your alt-coin is still overhead for miners, they need some extra reward on top of bitcoin reward.

I still think having a minimum of one satoshi per share is a problem.  The shares themselves should have no value besides that of the company.

Technically it's possible to make use of zero-valued outputs, but it's PITA.

Don't forget that ownership of share is granted by some paper, that paper has some value too. (I.e. it can be recycled.) But usually value of paper is so low compared to value of share that people don't care.

Likewise I think it's safe to say that 1 satoshi's value is negligible compared to value of share.

Even if it's not, you can simply account for it. I.e. value of a colored coin is a value of share + 1 satoshi.

[killerstorm]

Correct.  A small bit of transaction metadata has been proposed, however:  https://github.com/bitcoin/bitcoin/pull/1809

If they object say that we'll just use 2-of-2 multisig for tagging then. That would be worse for everyone.