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

I understand the approach regarding binding of asset/contract/... to color and I agree this is a good approach. Maybe concering yourself with implementing the "higher level" should have low priority.

Thank you! Especially for supplying your example John Smith contract you put in quote above, maybe this could be put somewhere into the "intro" document (https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro).

No.

Suppose you have just installed NGCCC. In its initial state, it only knows about bitcoins, and isn't able to recognize any colors.

But you, as a user, is interested in some asset. So you instruct it: "NGCCC, I want you to track certain colored colored coins using parametrized color kernel OBC. Their genesis is X:Y. Please call them Foo".

NGCCC will add a record like "OBC:X:Y = Foo" into its configuration file so it will be able to remember about this association between name and color.

And now it is able to recognize these Foo-coins.

Issuing transaction is just a normal transaction. It simply acts as a starting point: next transaction will spend its output, and so on.


Blockchain has information about transfers of colored coins.

Everything else can be stored elsewhere.


We use a layered model.

Lowest layer is the colored coin model, it is about color kernel and colorvalues. Contracts simply do not exist on that level.

Contracts can appear on higher levels, but so far we haven't fully implement this higher level. But the thing is, it can be implemented in many different ways, and it isn't of utter importance.

I believe it's better to keep it manual for now.

E.g. suppose John Smith wants to issue 1000 bonds with face value of 1 USD each. To do this he will write a message like


Then John Smith will sign this message using GPG and will post it in on forum. If there are people who trust him, they'll check if GPG signature is valid.

If they are willing to trade these bonds, they will add color mentioned in the message into their colored coin client.

Of course, we can create a special format for these contracts, make some kind of database where they can be published and so on.

But right now it isn't necessary: people can just use whatever they are comfortable with.

Colored coin software is just a tool which tracks coins.

Thanks a lot for your above explanations about "storage locations", Meni.

On the last point I quoted: What benefit (or downsides) could a hash of the contract inside the blockchain have?

The data has two parts, the color definition which identifies the color and its meaning, and the transactions which indicate movement of colored coins.

The transactions are completely normal Bitcoin transactions stored on the blockchain.

The color definition is "out of band". The most important place it should be stored is probably the issuer's records, if the issuer itself doesn't know how to treat coins of his color that's a problem. It should also be visible in some public place such as a company website or a repository so other people know what the color represents too. Lastly, every end-user client interested in this color should download the color definition and store it, perhaps in the wallet file, so it can recognize coins of this color.

The color definition connects the blockchain with a real-world entity so there is little benefit in having it inside the blockchain itself.

I understand. Yes, please change the title, it's hard enough for newbs to find the relevant stuff about colored coins.


I would like to seconds this question regarding color kernel and parameter "storage location"? Do I understand correctly that the color kernel is defined by the issuing transaction and that data is stored in the blockchain?

This leads me to next question: is any data stored off blockchain at all?

This leads me to yet further question: where/how is "association" of color with a contract "stored"?

sorry for being so lazy and just out-right asking these newbie-questions

also: thanks, killerstorm for writing this: https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro, it really helps

Well, previously I was working on a different client, called ArmoryX. Since many people already follow this thread, I decided to continue posting updates in it. I guess I should rename it....

What data?

If you're talking about metadata like name, contract, etc., then it can be anywhere. E.g. somebody might post on forum that he is selling shares of his company foo, and you canl add this asset definition to your client, like


Now it can show you your foo balance (how many shares you have), you can buy and sell them. Of course, client doesn't care what "foo" means.

If you're talking about ownership data, it is encoded in Bitcoin transactions. These transactions look exactly like normal Bitcoin transaction and do not have color tags or anything. But client can trace them back to the genesis transaction my going through the transaction graph, and that's how it knows that it represents ownership.

I'm sorry, I'm just dropping in here triggered by reddit all confused about colored coins implementations.

Why is this thread called ArmoryX while the implementation talked about seems to be called ngccc?

Nice work!

Where is the actual data saved which is associated with the coins?

We are also looking for JS developers to work on WebcoinX.

Here's a list of tasks: https://trello.com/b/n4qoNDDI/webcoinx (the most important ones are on 'Future' deck).

Interested developers should send me PM and describe:

• their experience (particular, familiarity with things like binary serialization, Bitcoin protocol, OO design)
• availability (how many hours per week can you allocate on this, how soon)
• expected compensation (we have 30 BTC bounty pool for the next iteration of WebcoinX, but it is open for discussion)

Currently the focus is on the thing called ngcccbase: we're going to start with a command-line client (we'll make network daemon and GUI versions of it later, using the same core).

It is currently barely able to show balance, but all the infrastructure is there. It need many improvements before it is usable.

Repo: https://github.com/bitcoinx/ngcccbase

List of available tasks: https://github.com/bitcoinx/ngcccbase/issues

The process:

• anybody can grab a task
• the requirement is to report progress often. the plan is to make a working version in matter of weeks, so even few days of delay can have detrimental effect
• fork ngcccbase repo, write your commits, create a pull request
• in pull request, please mention how many hours you spent on it (you're supposed to track them, but guesstimation is OK)
• bounties will be rewarded proportionally to hours spent, as long as they are reasonable
• total compensation pool is 30 BTC, but we need to do a lot of development, and it isn't possible to tell what one hour of work will be worth.
• if you do not like uncertainty you can offer to implement a specific task for a fixed bounty. drop me a note in this case

Ok, helped me understand. To me, colored coins is truly an exciting concept and I'd like to see it grow. Being a senior developer myself, how can I help?

Bitcoin protocol supported multi-signature scripts from the start, but we still do not have a usable user-interface for things like dispute mediation, escrow etc.

This clearly shows that having something available in protocol isn't enough. Somebody also needs to build a user interface and infrastructure around it.

Same is true for colored coins protocol: protocol is simple, the trick is to implement a complete, usable solution.

People who develop "existing clients" need to focus on needs of majority of Bitcoin users, they need to implement features which make Bitcoin a better payment system. For example, a payment protocol is currently being standardized and implemented.

On the other hand, there is no reason why I can't make a new, experimental client. If I fail at that, it won't be a big problem.

Another thing is that implementing something in code is actually no different from writing thorough specification. What is code if not a formal specification of how program should work? (Well, you can say that code is too specific, but it really depends on how you write it, e.g. Haskell can be very similar to math notation.)

So I would rather write code and get something working than do it on paper first.

Besides that, colored coins have this property that the core is very simple, but when you actually try to implement it in a wallet, you run into a number of problems.

Also you probably overestimate how hard it is to implement a new wallet... Plazmotech implemented the first version of NGCCC in three days. Implementing a wallet per se isn't hard. It is hard to make sure that it is secure, reliable, fast, etc.

I don't get it. Why don't you focus on delivering a clean, well-documented protocol instead and let the existing clients implement it?

At the stage we are at, we cannot make incremental progress. We have something working, a prototype, but to make progress we have to re-arrange things, and such re-arrangements affect overall design.

I cannot say: we need foo, then bar, then baz. Because that's just one idea. Perhaps a talented programmer will join and say: we can do quux and frob instead, and it will be better than what I thought.

If you want to see some list, here's NGCCC overview:
https://github.com/bitcoinx/colored-coin-tools/wiki/The-next-gen-colored-coin-client

And here's WebcoinX bugtracker: https://trello.com/b/n4qoNDDI/webcoinx

But that's pointless. I don't want people to grab tasks to do, I want them to discuss development strategy first.

It's really hard to put a price tag on it, as it depends on many factors.

First, it isn't clear what kind of features is required... It is definitely cheaper to develop simpler software.

But some people absolutely want a web client, and it's messy, we have to make several trade-offs to make it work.

Also, programmer labor costs vary a lot... Hiring someone from California is one thing, hiring someone from India is another.

And we need people well-versed in cryptocurrencies to do this (well, for most important parts), and it's hard to find them available.


Are you referring to something specific?


Well, maybe. I currently have an agreement with a sponsor, they are willing to provide $10000 for a colored coin client. I think it's enough.

But I haven't found programmers who can spend significant amounts of time and efforts. (See my other post.) I talked to some people, but nobody said "I can spend 1 month on this if you pay me $xxxx".

Just as a point of reference, this Spring we had a fairly good JS developer working in WebcoinX, he got something like $2000 worth of Bitcoins for 2-3 weeks of work, and made a very basic WebcoinX. (He was making a good progress.) But then he disappeared in June (I suspect something happened with him IRL).

Well, I hope so... A year ago there was a lot of interest after GLBSE collapsed, but very few developers contributed to the effort.


We have multiple software projects, and all of them are not quite ready for the mainnet for various reasons.

Also, there is no specification, but design was discussed on the mailing list, and once we finally decide on what to implement in software, it won't be a problem to compile it all into a specification.


We need to scan the blockchain for transactions involving colored coins, and blockchain is large, so scan takes a lot of time. There are many ways to optimize it, but we didn't implement them yet because of a lack of manpower. Reasons are different for each software project:

1. ArmoryX was slow to initialize, simply because it is Armory. New version of Armory uses a different design, so maybe it would be faster. But it takes several hours to initialize Armory for the first time.

2. WebcoinX is slow because it does backward scan and fetches transactions one by one. There are many ways to optimize the process (particularly, we're going to change coloring scheme to help this), we just haven't had a chance to implement it. But then it scales poorly with a number of colored transactions, we'll have to employ advanced cryptography to make it fast.

3. NGCCC/coloredcoinlib is slow because it scans blockchain via bitcoind's JSON-RPC API, one transaction at time. It will be faster if we grab whole blocks (probably), also use of an external service can drastically speed up the initial scan.


Well, a bug in colored coin wallet software can result in destruction of colored coin.

 Same is true for any cryptocurrency software. You know, there are several documented cases where software didn't include change output, and so a large amount was sent as a fee... IIRC it was 200 BTC in one recent case. I.e. somebody lost $20000 worth of Bitcoins just because someone forgot to add one line of code to a script. (Miner returned money in that case.)

Of course, being aware of this problems, we should design our software to prevent them, and add extra checks to prevent problems before shit hits the fan.

Also, we have improved the theoretic model we are using and approach to wallet implementation in May-June, so many of old concerns are no longer relevant.


I'm not aware of any problems which can get in the way of the approach I'm currently using (i.e. specifically "order-based coloring" and "padded order-based coloring"). But this issues was brought up in Spring, and I think the best way to address this is to make migration to a different system easy.

The general idea is that it is always possible to identify an owner of a colored coin at a certain block, so it's possible to offer an automatized migration process as owner can be authenticated automatically.


NGCCC and WebcoinX are being developed in parallel.

NGCCC will rely on a local bitcoind, and use external services for speedup. Currently we have some crude prototype (called CCoinDemo), I'm working on making it fast, secure and usable. I'm working on it alone.

I think NGCCC is the shortest path to a secure, independent colored coin client. But it might be somewhat inconvenient as it requires local bitcoind/bitcoin-qt.

(Although it has flexible architecture, so it's probably possible to add an option to use electrum-server.)

WebcoinX is a web client, we are currently working on a testnet demo which will showcase colored coin.

Also we plan to make it secure and make it work on mainnet, but progress is little to non-existent because out of a team we have now only I'm able to work on its core, and I don't have time for this between NGCCC and posting shit on forums.

If more developers will join the effort, plans can change. For example, we can make a colored coin version of Electrum. It all depends on who joins.


There is some discussion in mailing list/google group: https://groups.google.com/forum/#!forum/bitcoinX

But discussion about specifics of development is in email.

To progress faster, we need more developers.

But not just more developers, we need developers who can participate in design of protocols and architecture, who have opinion on various design considerations, and who can make decisions on their own.

Even though we do have several developers now (working in their free time, i.e. after the day job, on weekends, etc), but only I'm responsible for all planning, design architecture, etc. So it is the bottleneck: when I'm not making a progress, project isn't making a progress.

So in the light of btct.co announcement, it is a pressing issue now. It might be a good opportunity for issuers to switch to colored coins, but software isn't ready yet, and if we won't increase development speed, it will be too late.

There are many competing projects, for example, Bitshare, Freimarkets, Mastercoin.

But with colored coins we had almost-working software back in January of 2013, and design was reviewed by many people, so it might be the best thing to deploy quickly.

Also colored coins is one of few projects which allows trading in Bitcoins directly, with no reliance on 3rd parties.

The only other one I'm aware of is Mastercoin, but Mastercoin's design is often criticized as being immature.

I don't see any bugs/issues open on Github for any of these projects.  If you're looking for external developers to join you should keep a TODO list or a bug tracker somewhere (even if it's just you working on the project for now).

An estimate of how much money needs to be thrown at it to get it ready for them to use would probably be useful...

People have been throwing $300,000 a shot at stuff lately it seems, would this be cheaper than that to deploy, do you think?

-MarkM-