Same here Adam

You wish BTC price drops down? Why? probably you are one of those who've sold all their bitcoins ~ 12$. There is one major fact that you would argue about, that most bitcoiners wants BTC price to drop down for one and only one reason: "buy back at lower price". For that I expect BTC price to keep swinging in the range of 10 to 13 for the coming month. But I am really wondering what will happen when the block reward drops to 25 BTC. Are we currently witnessing the last down wave before the 25BTC block reward?

Could you please post the links?

There is no decentralized mechanism for exchange in all current colored coins protocol designs. That is the main issue that motivated me to work on a new design. If shares ownership relies on the issuer/share holder to transferring their shares to another shareholder, there would be no roam for any sort of a decentralized exchange mechanism within such protocol. It is that particular point that forced me to redesign the protocol in a manager that shares ownership wouldn't be related to any sort of colored coins. In order to create a mechanism for a decentralized exchange, share holding should come as reflection/output to such exchange. So shares movement from one node to another should take place on multiple stages:

1- Node ["A"] broadcasts a sell "ASK" order and a BTC address to receive payment on
2- Node ["B"] broadcasts buying the shares broadcasted by ["A"] "or portion of it"
3- Node ["B"] sends the requested BTC amount to node ["A"]'s BTC address
4- The application automatically parses steps (1,2,3) and moves ownership for the shares bought on (3) from node ["A"] to node ["B"]

The broadcast mechanism will take place as transactions sent to the issuer's BTC address, while all nodes are monitoring all transactions send/received by the issuer's BTC address. That would result in a real time messaging protocol on top of the block chain. Transactions sent to the issuer's address will be parsed as binary protocol events. Where the last "one or two number" will be parsed as an event id: {"0.00000001:issue","0.00000002:buy","0.00000003:sell","0.00000004:ask",...}. The most challenging part now is optimizing the operations/transactions to its minimum.

Your feedback is more than welcome.

I am currently experimenting/designing a new asset exchange protocol that will take place on top of the block chain for assets issuing/buying/selling/...

My design is radically different from any current colored coins design. In colored coins the asset starts being tracked from a root transaction where all coins in such transaction is considered to be colored. In my design there is no such a thing called colored coins.

The protocol will treat btc addresses as nodes in a network. Where transactions are gonna be used as network events being sent from one node to another "BTC address to BTC address". All communication is going to go through a single point of interaction which is the "issuer's BTC address". The history of all transactions made to the issuer's BTC address will be parsed as issuing/ask/bid/buy/sell/motion/buyback, in a manner that after parsing the whole transactions history made to and from the issuer's BTC address the application can determine which btc addresses owns how many shares, which btc address is selling shares and @ what price and so on. In simple words the design will relay on tiny payments being sent to the issuer address as protocol events/service fee. The payments made to the issuer's address are gonna be treaded as messages/events where the issuer can benifit from it as operation fees. There will be no worries about assets being mixed "multiple colored coins transfered in one transaction". Cause the design by its nature will hook all the asset activities to one BTC address "the issuer's". In fact there will be no colored coins at all. A BTC address can hold 1000 shares of an asset where its btc balance is = to zero.

If you've ever experienced a lucid dream, you would more likely believe that reality is a governed projection of conciseness. It feels real when your connected/tuned to the same level of conciseness. Who knows, we may be traveling between multiple levels of conciseness all the time without even realizing it.

The method of exchange you've explained is the only possible way in the current design and that is exactly what I am trying to stay away from. We still need a decentralized exchange mechanism, why?

• Cause trust should be imbedded within the mechanism itself instead of person to person exchange
• Also we need a decentralized mechanism to broadcast ask/bid orders instead of relaying on a "centralized" third party client/server mechanism
• Remember that the main reason we end up being here is strongly related to "TRUST", we need a simple user friendly application that we can trust more than any other centralized solution

What would be more interesting is instead of sending the message in the transaction fee, is to send the message as a small BTC amount to the issuer's BTC address as a second recipient in sendmany(). This way all messages related to that particular asset can be tracked through the issuer's BTC address. The issuer can then benefit from the messaging mechanism instead of wasting BTC in the transaction fee.

What do you mean by "affording a transaction but can't afford the transaction message you want" can you give an example?

If you just make use of the last 2 digits in the transaction fee: 0.000000## this can give 100 different variation = 100 different events/messages

I don't think that you would need more than 100 different messages, knowing that currently your design is based on a single message: colored coins moving from one address to another. Imagine if you can have 100 different events/messages going in/out of a BTC address. In this case you wouldn't even need to move the colored coins! the colored coin term wouldn't even apply here. Cause by then you would be applying a virtual messaging protocol on top of the block chain, where nodes = BTC addresses, messages/events = transaction fees, message/event payload = the value being transfered. Only then the variations that such design can give would allow a decentralized exchange mechanism to take place: You want to sell 10 shares @ 0.1? send a transaction to the BTC address you want to receive payment to with the value you want to accept per share and a transaction fee with last digits = to the "ask order" message/event. The same senario can be used in buying the shares. Does that make any sense?

I am looking forward for your exchange mechanism solution. Where can I follow that?

What do you think about using transaction fees values as messaging protocol events for a colored coins application? Do you know of any implementation that applies that?

As far as I understand your design doesn't have a mechanism for exchanging "shares/colored coins <-> BTC". I am still new to the term "colored coins", I came across it when I was trying to find any decentralized solution for exchanging Assets <-> BTC. Your design seems idle for issuing/tracking colored coins ownership. I am thinking to start using your implementation soon for my asset "Bitnodes". Please correct me if am wrong; there is one problem/feature that is missing in all colored coins implementations that I've researched, which is "a mechanism for exchange". I wouldn't argue that such exchange mechanism is beyond the concept of colored coins. What I mean by an exchange mechanism, is to have a mechanism to create ask/bid orders, and to be able to perform the exchange automatically in a decentralized manner by only relaying on the block chain and the colored coins software.

I just think about it as a second layer of securing the colored coins. Actually I came to this point not only to guard colored coins but to make use of the transaction fee value as a messaging protocol command.

Yes, I am planning to do so soon.

Is it possible to force a specific transaction fee to any colored coin transaction?

For example: a transaction fee of 0.00050321

In this case the colored coin application/script should:

• Always use such specific "fixed" transaction fee value in transferring colored coins
• And in return, ignore "doesn't interpret" any transaction that doesn't have such "fixed" transaction fee

This way the application can guard colored coins from accidentally being spent.

When I first created this thread, I wasn't aware of the term "colored coins". Thx for everyone who've posted to this thread, your posts were very informative.

It seems that colored coins is going to be used pretty soon in replacing GLBSE. I am personally thinking about moving my asset "Bitnodes" to colored coins. Currently I am examining this solution: https://bitcointalk.org/index.php?topic=117630.0

So what would such colored coins be then? and how it would come to existence?

It seems that Avalon still accepts orders @ 1299$ though the pre-order date had passed. I am not sure if the price will remain @ 1299$. Despite how much avalon ASIC price will be in the future, still Icarus boards will have a trade/upgrade plan.

Email them, they would help you on that. Be patient as it usually take them long time to reply.

If you are interested in buying Icarus boards to mine today, then upgrade it to ASIC whenever avalon ASIC is available, check my Icarus sale thread here: https://bitcointalk.org/index.php?topic=115154.0

Zhang "the developer of Icarus" is developing ASIC miners each running @ >= 60 Ghash/s for US$1299. Zhang announced that any icarus or lancelot user can trade-in their icarus or Lancelot mining board for 300USD (icarus) or 400USD (lancelot) "every new 60G mining machine can only trade-in one old mining board" Source: https://bitcointalk.org/index.php?topic=110090.0

This means that if you buy Icarus boards today @ 300 USD then upgrade the boards to Avalon ASIC @ 300 USD per board, you will then have the opportunity to mine for "2 to 4" months without losing any of the boards initial value.