Quote from: killerstorm on November 27, 2013, 11:32:11 AM

Quote from: zathras on November 27, 2013, 10:26:31 AM

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.

Quote from: zathras on November 27, 2013, 10:26:31 AM

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!