Adding a distributed way for MasterCoin to evolve

[Ron Gross]

I think that above everything else, MasterCoin is an infrastructure with yet unknown capabilities. As one of the first tasks in the MasterCoin protocol, I would like us to implement a way for MasterCoin holders to vote on protocol changes (hardforks).

Before proposing a way to evolve MasterCoin past forking changes, I'd like to explain how MasterCoin can have forks, even though it's not really mined. MasterCoin 1.0 was defined in Willet's original whitepaper ... but Willet is not the master of MasterCoin. If everyone in the world except Willet decides to add feature X to MasterCoin and call that "MasterCoin 1.1", then this will be the de-facto new MasterCoin. The new MasterCoin can contain new operations and transaction types that Willet's original spec does not support, and so the two "worldviews" of MasterCoin 1.0 and MasterCoin 1.1 will diverge - in other words, when we let the MasterCoin 1.0 program parse the Bitcoin blockchain, and also let the new MasterCoin 1.1 program parse the same blockchain, they will disagree on the balance each address contains (1.1 might even contain new types of addresses unrecognizable by 1.0)

With Bitcoin, there is a clear, decentralized way for miners to vote on protocol changes - by hash power. In MasterCoin, there are no miners (well, they're hidden in the Bitcoin layer and are irrelevant to MasterCoin).

I propose the following protocol that MasterCoin can use to control its own evolution:

1. We build one reference implementation of MasterCoin 1.0

2. We now encode the hash of the git commit for MasterCoin 1.0 in MasterCoin's own code, forming MasterCoin 1.0.1. Everyone starts running MasterCoin 1.0.1.

3. Whenever there is a desire to add a forking change to MasterCoin, anyone can publish a protocol change request  into the MasterCoin network using a special message (the message contains a URL of a repository and a git commit hash within that repo).

4. Owners of MSC can vote whether they approve a particular valid fork request (a fork request is valid if its git commit hash is a descendant.of the currently accepted master hash.

5. Once more than 50% of all MSC have voted on a particular fork, it becomes the new standard, and everyone should upgrade to the new client (or else, they will be stuck on the wrong side of the fork).

(The above assumes that Willet will control less than 50% of all MSC).

BTW the above kind of reminds me the rules of Nomic ... it can get quite crazy.

[jr.wi...@gmail.com]

This is absolutely correct! I plan to be completely pragmatic, implementing whatever features will make MasterCoins more valuable, but if somebody REALLY wants a feature and I haven't implemented it, there is nothing stopping them. Their version wouldn't be compatible with mine, which might cause some confusion though. Hopefully they would use Test MasterCoins for their experiment.

I do like the idea of voting on which features come next. I'm guessing it would be best for me to abstain from such voting, regardless of how many MasterCoins I have.

[Ron Gross]

You'll be responsible of deciding which pull requests to merge ... until you merge the decentralized voting pull request, which will remove you from the "decision throne".

I don't think you ought to abstain. Perhaps it would be wise at first, but if MasterCoin are to be successful, at some point the relative amount of power (and MasterCoin!) you own, compared to the public, should become minor.

Ron Gross

Co-Founder & CEO @ bitBlu

bitblu.com    |    ripper234.com

Schedule my time at meetme.so/RonGross

--
You received this message because you are subscribed to the Google Groups "MasterCoin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mastercoin+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.