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

How did it work with HTTP dev? I'm not familiar. (Actually, was how that was developed even relevant to us?)

Well, you need something to test it against, so you need a formalized model and spec first.

This is what I was talking about.

In case with colored coins, each color is independent, and can be fairly simple. It's trivial to "feature freeze" a color (at least in terms of ownership), and then, technically, there might be bugs in wallet implementation, but semantics is 100% clear.

But Mastercoin is monolithic and feature-full. Each feature can potentially interact with each other. Getting a stable Mastercoin implementation with sane upgrade policy is very hard IMHO.

I hope you do not recommend people to trust their money to something which "don't have anything 'stable' - not even close" and is in "rapid prototyping" stage.

So I said that we'll likely get a usable colored coins usage way before usable Mastercoin exchange. But Ron and Taariq pretend that it's non-issue, like, we have a spec on github, hence consensus is guaranteed.

Really? This spec is nothing. It is way too vague. You haven't even tried to formalize interpretation of the spec or anything like that.

For example, it defines that rate-limited address cannot be used for decentralized exchange. This makes sense, of course.

But what if a command to make address rate-limited is sent after an offer on decentralized exchange is made? Will it cancel the offer, or will command be ignored?

If implementation X cancels the offer, while implementation Y ignores a command to make address rate-limited, it is possible to double-spend.

You need to define a formal model of Mastercoin transactions, e.g. a state variables are associated with each address. And then you can describe how each command modifies state variables of addresses which are involved.


Actually, no: Satoshi released a complete version of a client, and Bitcoin developers were always reluctant to change things which can affect consensus. Almost no features were added to the protocol in these 5 years. If anything, many features were disabled.

Couldn't agree more on encouraging more testing - there is 100BTC ($100k+ as of right now, even Google max out at $20k for the most severe bugs) already in bounties for incentivising testing.

During my one comp sci class, I think I learned that the majority of work (at least cost of time wise) involved testing. I'd like to encourage this somehow to have more help on the testing front. Bug bounties a la google et al to preserve a rigorous spec.

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!

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.


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,

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:

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.

Nice work.
Following.

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.

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

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.

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.

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.

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

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

Yup! I also want to see it

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

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.

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.)

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