Protocol changes and voting


#1

@Seneca brings up a good point in "How does the community decide things."
What is the mechanism by which the network protocol is changed. This includes possible changes to how safecoins are farmed and recycled. It would be nice if the initial design was perfect, but I don’t think that we can assume this will be the case. There will be situations where the community wants to change or upgrade the network in a way that is not backwards compatible. We need a way for the community to bless a new version and a mechanism for the nodes in the network to make the transition.

In bitcoin, there is a mechanism to do this voting. Lets say, for instance, a new version of the bitcoin protocol is proposed (v0.8). Lets say the network is currently on block 100,000. A specific block in the future is chosen to make the transition to v0.8, lets say it is block 130,000. In every block between 110,000 and 130,000, the miner has the opportunity to vote on whether to transition to v0.8 or not. This is recorded in the block itself and saved to the blockchain. After block 130,000, all of the votes are tallied up. If the majority of votes approve v0.8, then block 130,001 and all later blocks will use the new protocol. If the majority of votes reject v0.8, all blocks continue on using v0.7.

I think a similar scheme could be used in the SAFE network. Questions can be posed to the network, with a set number of votes required to make a determination. These might be protocol changes, or changes to the recycle rate of safecoin, or even board of director appointments to the foundation. I could see a situation where regular votes are made to help balance the recycle/farm rate of safecoin.

Every time a farmer creates a coin, they have the opportunity to cast a vote on any currently open questions. When a question collects the required number of votes, it will be set as decided and any changes required to the functioning of the nodes can occur automatically at that time.

I think this will work, but it is not ideal. The farming community is not the only stakeholder in the network. I would be afraid this sort of design would lead to an unbalanced system that favored higher costs (and farmer payouts) than were strictly necessary.

I propose two houses in the SAFE government. The farming house and the user house. The above scheme is used to determine the vote in the farming house. In a similar way, every time a user pays a coin to the network, they are allowed to cast a vote to any question currently open in the user house. These votes are tallied in the same way as the farming house. Any change will only be successful if it is passed in both the farming and the user house.

There is one problem with the user house. A person will be able to cast a large number of votes by burning their safecoins and donating them to the network. This would cost value, but it is not as secure as the farming house where a person would actually have to provide an outsized amount of resources to swing a vote. This is why I proposed two houses that vote independently, instead of adding all votes from both schemes.

I would like to be able to add a third house, the “builder” house, comprised of developers that build applications on top of the network. However, I can’t think of a mechanism to allow them to cast votes.