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

[Flavien]

And to me, the only way colored coin will take off is by getting partners willing to emit colored coins by backing them with real assets. Bitstamp for instance could emit USD colored coins, since they already do that with Ripple.

Well, currencies isn't the only use case for colored coins. In fact I see more interest for capital market use cases.

But there are also people/companies interested in what you described above.

There are two possibilities if you want to use colored coins for securities:
1: The security is not native to the blockchain (such as an AAPL stock), in which case, everything I said applies. You need to be able to redeem your colored coin for an actual AAPL stock. That will only happen when stock brokers decide to support colored coins, which is way down the road (will happen much later than my use case with Bitstamp and USD).
2: The security is native to the blockchain, let's say someone decided to go public with their company and emit shares on the blockchain, but the challenge is making sure that "colored coin as equity" is recognized by the law (given the amount of regulation around that, it's fair to say it's not).

[killerstorm]

1: The security is not native to the blockchain (such as an AAPL stock), in which case, everything I said applies. You need to be able to redeem your colored coin for an actual AAPL stock. That will only happen when stock brokers decide to support colored coins, which is way down the road (will happen much later than my use case with Bitstamp and USD).

Have you ever heard about CFDs?

http://www.etoro.com/

2: The security is native to the blockchain, let's say someone decided to go public with their company and emit shares on the blockchain, but the challenge is making sure that "colored coin as equity" is recognized by the law (given the amount of regulation around that, it's fair to say it's not).

ActiveMining considers doing that. As for legality, it's definitely not worse than shares on BitFunder or "direct shares".

I think if company is a scam, it will find a way to scam you even if contract is recognized by law. And if it isn't a scam...

[tiaguitah]

any new progress on colored coins? :p

[killerstorm]

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.

[kslaughter]

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.

Are they padded?

[TKeenan]

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.

I'll bet MSC distributed exchange will have 10,000 transactions before you have 100. 

[killerstorm]

Are they padded?

No, currently only simple OBC is implemented. It's enough for the demo/testing of other components.

We consider several coloring schemes. The one designer by Peter Todd looks even more promising than POBC, but it's not finalized yet.

In any case, adding a coloring scheme isn't a big deal because they are self-contained. (Basically, each one is a separate class.)

[killerstorm]

I'll bet MSC distributed exchange will have 10,000 transactions before you have 100. 

1. How much do you bet?
2. Mastercoin distributed exchange is for MSC<->BTC trading, this one is for trading securities. It isn't the same thing, is it?
3. The problem with Mastercoin is lack of finalized specification. Difference between multiple implementation can result in monetary loss. On the other hand, in case with colored coins, an implementation of color kernel can serve as a finalized specification: you can just keep using it, it will never change. We can implement other kernels, but they do not invalidate older kernels, different kernels can peacefully co-exist.

[dillpicklechips]

any new progress on colored coins? :p

Yes. I've mostly finished with p2ptrade. It lacks checks and cuts corners in some places, but is able to make transactions. Here's the first transaction made using ngccc's p2ptrade:

https://blockchain.info/tx/fb5656cafe75c5723152b128c6c52b5514787d34125a303908dc018bdd048410

I hope we'll be able to make a demo release in a couple of days. We already have almost all components in place, but it works only in dev configuration. Also we might need some testing/debugging/improvements etc.

We are also pretty close to a beta release: while there are things which need to be improved, they aren't numerous, and having a big team we can do a lot of work in a short time frame.

I can't wait to see it! I'm glad things are accelerating for you!

[HostFat]

Yup! I also want to see it

[killerstorm]

p2ptrade GUI screenshot: https://i.imgur.com/VlVw6cT.png

(it needs some bugfixes/improvements to work properly, though.)

[ripper234]

1. How much do you bet?
2. Mastercoin distributed exchange is for MSC<->BTC trading, this one is for trading securities. It isn't the same thing, is it?
3. The problem with Mastercoin is lack of finalized specification. Difference between multiple implementation can result in monetary loss. On the other hand, in case with colored coins, an implementation of color kernel can serve as a finalized specification: you can just keep using it, it will never change. We can implement other kernels, but they do not invalidate older kernels, different kernels can peacefully co-exist.

2. We're pushing forward our securities / Smart Property feature. We just hired Taariq Lewis to lead that effort, and are gearng up to accelerate both the bizdev and coding.

3. What do you mean "finalized spec"? We are evolving and adding new features all the time (spec is on github) - how is that bad? We have a spec for Smart Property already in v1.1 of the spec, but are open to modifications / bug fixes if needed, and are coordinating the information flow between all the developers.

[killerstorm]

3. What do you mean "finalized spec"? We are evolving and adding new features all the time (spec is on github) - how is that bad? We have a spec for Smart Property already in v1.1 of the spec, but are open to modifications / bug fixes if needed, and are coordinating the information flow between all the developers.

Do you understand a concept of hard fork? Each update to a set of rules needs to be done in such a way that all clients will be updated before new rules are in effect.

If two client implementations can disagree about a results of a transactions, it might be used for double-spending.

If you do not have an update schedule, clients will be updated at random points and they WILL disagree.

This is what I meant by "finalized spec": you have to do a feature freeze at some point if you want Mastercoin do be secure.

[tlewis]

I'll bet MSC distributed exchange will have 10,000 transactions before you have 100. 

1. How much do you bet?
2. Mastercoin distributed exchange is for MSC<->BTC trading, this one is for trading securities. It isn't the same thing, is it?
[snip]

Unfortunately, #2 is incorrect. The Mastercoin distributed exchange goes well beyond the trading of securities to include any particular asset.

"Mastercoin supports creating property tokens to be used for titles, deeds, user-backed currencies, and even shares in a company. Whenever property is created, it gets assigned the next available currency ID, so any property can be bought, sold, transferred, and even used for betting, just like other Mastercoin-derived currencies."

Source: https://github.com/mastercoin-MSC/spec#smart-property

I'll be adding more details around the opportunities on this functionality in blog posts coming up and would definitely like to continue to explore the contrasts between Mastercoin and Colored Coins.

[ripper234]

Do you understand a concept of hard fork? Each update to a set of rules needs to be done in such a way that all clients will be updated before new rules are in effect.

If two client implementations can disagree about a results of a transactions, it might be used for double-spending.

If you do not have an update schedule, clients will be updated at random points and they WILL disagree.

This is what I meant by "finalized spec": you have to do a feature freeze at some point if you want Mastercoin do be secure.

Alex, you have known me for enough time, I would expect you to rightfully assume I understand hardforks. In any case the answer is yes.

I don't think we need a feature freeze, we just need to think more carefully about the spec changes schedule.
Thanks for bringing this issue to our attention, I'll send it to our developers and J.R. for consideration.

[overcoin]

Nice work.
Following.

[killerstorm]

Alex, you have known me for enough time, I would expect you to rightfully assume I understand hardforks. In any case the answer is yes.

I don't think we need a feature freeze, we just need to think more carefully about the spec changes schedule.
Thanks for bringing this issue to our attention, I'll send it to our developers and J.R. for consideration.

Cryptocurrency is secure only under condition that there is a consensus among all clients. If you cannot guarantee that, that means that cryptocurrency you're developing isn't secure.

By "guarantee" I mean that you can prove that problem like that cannot happen under certain assumptions. Of course, bugs are possible, but you need to demonstrate that you're doing the best effort to prevent problems.

If you're piling on features instead of implementing secure update mechanism that means that security is a low priority for you.

I think this problem was brought up many time before, I don't see why it is news for you.

[zathras]

Alex, you have known me for enough time, I would expect you to rightfully assume I understand hardforks. In any case the answer is yes.

I don't think we need a feature freeze, we just need to think more carefully about the spec changes schedule.
Thanks for bringing this issue to our attention, I'll send it to our developers and J.R. for consideration.

Cryptocurrency is secure only under condition that there is a consensus among all clients. If you cannot guarantee that, that means that cryptocurrency you're developing isn't secure.

By "guarantee" I mean that you can prove that problem like that cannot happen under certain assumptions. Of course, bugs are possible, but you need to demonstrate that you're doing the best effort to prevent problems.

If you're piling on features instead of implementing secure update mechanism that means that security is a low priority for you.

I think this problem was brought up many time before, I don't see why it is news for you.

Hey Killerstorm,

This is essentially what we're doing, developing our clients to a consensus and locking in and updating the spec where there are areas of ambiguity.  We're still very young so this is obviously a work in progress, but we have a very collaborative team that works together to ensure our respective projects are on the same page (state-wise) in their interpretation of the spec.

FYI from our internal discussions regarding hardforks:

Can anyone think of any scenarios where such an action would be required in an uncontrolled manner?

To me a hard fork implies at a certain block we decide to change something so fundamental it renders previous implementations unworkable - so our response would be entirely dependent on the situation at hand.

A perfect example of this was adding obfuscation to Class B - this would have been very different with backwards compatibility etc being built if there had been non-obfuscated transactions out in the wild, but since we thoroughly vetted it was just Tachikoma & my test transactions we could safely drop support without any impact and there was no change control variant needed.

This is one of the core reasons I've been quite restrictive with my releases of late, because I want to make sure we're all on the same page decoding/validation wise as changing something after the fact when its in the hands of users under real world usage would be a lot harder to manage.  

Cheers
Zathras

[killerstorm]

This is essentially what we're doing, developing our clients to a consensus and locking in and updating the spec where there are areas of ambiguity.  We're still very young so this is obviously a work in progress, but we have a very collaborative team that works together to ensure our respective projects are on the same page (state-wise) in their interpretation of the spec.

Sorry, I don't think you understood me.

Suppose you have two branches of your application: stable and testing. Each branch goes through a number of versions, e.g. zathras.stable.3, zathras.testing.7.

Other developers do the same: they have two branches: stable and testing. Suppose there is version called Tachikoma.stable.7.

Now we can formulate a condition: if there are xxx, yyy, i and j such that: xxx.stable.i disagrees with yyy.stable.j, and there is a possibility that user A uses xxx.stable.i while user B uses yyy.stable.j, it is a very serious fuck up.

Note that this means that if your old version, let's call it zathras.stable.2 disagrees with some new version released by Tachikoma, let's say Tachikoma.stable.7, it is a fuck up.

How is it even possible to do this without fuck ups?

You should tie it to block numbers. Let's say zathras.stable.3 works only until block 275000, after that it tells user that he should upgrade. This means that if you want to update rules in a stable branch, new rules should be applicable since block 275001.

Of course, you don't need to be that rigorous with testing branches, but at some point you'll need to produce stable versions.

To me a hard fork implies at a certain block we decide to change something so fundamental it renders previous implementations unworkable - so our response would be entirely dependent on the situation at hand.

Sorry, but you have no idea what "hard fork" means.

Look, I'm not nitpicking, I'm trying to help. There is a huge disconnect between level of rigorousness applied by Bitcoin core dev team and Mastercoin developers.

It looks like you do not understand the consequences.

[zathras]

This is essentially what we're doing, developing our clients to a consensus and locking in and updating the spec where there are areas of ambiguity.  We're still very young so this is obviously a work in progress, but we have a very collaborative team that works together to ensure our respective projects are on the same page (state-wise) in their interpretation of the spec.

Sorry, I don't think you understood me.

Suppose you have two branches of your application: stable and testing. Each branch goes through a number of versions, e.g. zathras.stable.3, zathras.testing.7.

Other developers do the same: they have two branches: stable and testing. Suppose there is version called Tachikoma.stable.7.

Now we can formulate a condition: if there are xxx, yyy, i and j such that: xxx.stable.i disagrees with yyy.stable.j, and there is a possibility that user A uses xxx.stable.i while user B uses yyy.stable.j, it is a very serious fuck up.

Note that this means that if your old version, let's call it zathras.stable.2 disagrees with some new version released by Tachikoma, let's say Tachikoma.stable.7, it is a fuck up.

How is it even possible to do this without fuck ups?

You should tie it to block numbers. Let's say zathras.stable.3 works only until block 275000, after that it tells user that he should upgrade. This means that if you want to update rules in a stable branch, new rules should be applicable since block 275001.

Of course, you don't need to be that rigorous with testing branches, but at some point you'll need to produce stable versions.

To me a hard fork implies at a certain block we decide to change something so fundamental it renders previous implementations unworkable - so our response would be entirely dependent on the situation at hand.

Sorry, but you have no idea what "hard fork" means.

Look, I'm not nitpicking, I'm trying to help. There is a huge disconnect between level of rigorousness applied by Bitcoin core dev team and Mastercoin developers.

It looks like you do not understand the consequences.

Hey Killerstorm,

Thanks for your response, greatly appreciated.  I don't consider any feedback nitpicking and am always happy to hear all views

Rather than get into a debate on semantics regarding the meaning of "hard fork" I'd be interested to hear what others think about our development approach also.  For clarity though we don't have anything 'stable' - not even close.  Rapid prototyping (RAD) is the order of the day for now.

I would completely agree that the Bitcoin core dev team likely do have more structure and rigorousness applied, but that's a project (worth multiple billions) that has had ~5 years to get to this point - I believe a startup phase looks different but that's just my view.

Thanks!