Topic: ChromaWallet (colored coins): issue and trade private currencies/stocks/bonds/.. - page 24. (Read 97112 times)

Certainly it's not a problem to implement a simple version but there are many design options which can significantly affect characteristics.


High frequency trading requires fast response, i.e. you see an opportunity for arbitrage and you need to execute trade quickly, before market moves. With p2p trading it's hard to make sure that trades would be quick because it depends on your conter-party and on non-quite-reliable networking.

With slow and unreliable trade it's much more likely that bot will lose considerable amount money, so you have higher risks. So at some point certain types of bots become unpractical.

So it is not a problem but rather a potential feature: with faster trading bots will feel more comfortable.


Address can be used as an identifier, but color definition should include information about number of tokens issued (in most cases you do not want uncontrolled issuance), display name, identifier of corresponding contract etc.


What if previously they represented something else, do they represent both these things now?

You can see a discussion about multi-colored coins here: https://bitcointalksearch.org/topic/m.1266454

I'm starting to like the idea of this even more. This is definitely the best use of "coin taint" I've seen.

Taking your 2, and adding another 20 BTC donation
and adding link to a public document that started the documentation :
https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit

Anyone who wants editing rights, simply send me your email in a private message

Assuming most services for colored bitcoins will be able to see all the transaction prices of that color in the last block, and since all the trades are transparent, it will make any "bad" bots public very fast, and people holding those colors will not transact with them.

Bots play all sorts of games with flashing various bids and asks, then cancelling them.  Trying to trigger other bots or traders to make a trade, or change the bid/ask spread etc.  On mainline exchanges (NASDAQ, etc.) bots have been reported to intentionally flood the channel to lock out other players.  In bitcoin-land, DDoS is a sadly familiar tactic.  Lastly, you need to make sure a bunch of bots doing HFT don't suddenly dump gigabytes of data into the blockchain.

There is nothing fundamentally wrong with bots.  Well behaved bots that are moderate-to-low traffic are just fine.

I've to admit that I haven't Mike's decentralized solution in detail yet, but I don't see where the potential problems are.
There was a simple program for "p2p trading" called dark exchange that actually lacked an atomic trade method. I've been assuming that the rest would be simple all along.

What are the potential problems?

Also, what's the problem with bots?


Each issuing address represents a color.


I don't think it's necessary. Outside the chain, you mark your assets like...
Signed with pk1("these 200 satoshis that I move from pk1 at block X, represent 200 units of asset Y").


I think it is enough.
I don't like needing underlying satoshis, we could just allow people to issue assets without this limitation provided that they pay the fees in bitcoin. This way, outputs without the corresponding inputs would be allowed, just not counted as real bitcoins. For simplicity (or maybe I'm too lazy to think the complex cases), these newly issued assets would probably be better implemented with some tagging.


Hard to tell. We should probably discuss it for as long as necessary to avoid having competing schemes (not competing software).
There's probably a best solution or an infinite set of perfectly equivalent best solutions.
No advantage for having multiple "colored coins languages" comes to mind.

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

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


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.


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.


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



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.

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.

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://bitcointalksearch.org/topic/796com-redstarminingcom-the-oldest-public-mining-security-150ths-63257) - 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://bitcointalksearch.org/topic/blockchain-security-trackingcolored-coinssmart-contracts-short-python-script-117630) - 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.

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.


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" into the blockchain ;-)

Quote

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

Correct.

Quote

Quote

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.

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.


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

A couple pybond implementation notes:

1) pybond will add a "" 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.

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.

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://bitcointalksearch.org/topic/m.1235504

Rules for creation of correctly colored transaction: https://bitcointalksearch.org/topic/m.1203918
Rationale for these rules, with examples: https://bitcointalksearch.org/topic/m.1169974
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.

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.

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

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 

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-

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.