Interesting. How, exactly, would this vote occur? How would this prevent an unwanted currency from foundation; via some yet undefined algo or would there need to be a human authority to make such a decision? If the latter, who watches the watchers?
I envision that the development/management team would be responsible for including 'ballot questions'. People who control BKC value would 'vote' in a similar way to performing any other type of transaction. Just like the real world, lotsa people probably would not care about lotsa things enough to bother to vote at all.
How do you propose to enforce your vision?
It's not about 'my vision'. Open-source is not an easy concept to grasp. I'm sorry, but it's also not my fault.
From an implementation point of view and in the interest of balancing optimization against robustness, I might consider something like this:
- Developers (in conjunction with other leaders) implement highly important decisions as code which simply honors settings which only secret-key holders can induce.
- Once a decision has been reached ('the votes are counted') the next release might optimize the decision in code.
- For flexibility and visibility, the code with deals with decisions like this would probably be implemented as modular plugins.
Methods for verifying integrity and absorbing 'updates' and the like are quite solid and old hat at this point. If there is some focus on avoiding spaghetti code, and in particular, constructing a well thought out reference implementation for 'voting' which is auditable, that would go a long way toward developing the necessary level of confidence in the solution.
As for who watches the watchers, it's just like any other open-source project. If the development team is to corrupt or out-of-sync with the users, some other group will be successful in creating a fork. So, the users watch the watchers. Or are the watchers I guess.
Network effects be damned, eh?
The 'network effect' (as I visualize it) is a highly valued moderating factor in a well functioning open-source solution. Let's use Bitcoin as an example here:
Let's say that most people liked BIP17, but Gavin and relatively few others liked BIP16. He could still implement it and the project would not come off it's rails because it although a majority is annoyed and some of their hopes for certain things are dashed, it's not a show-stopper and a large part of the community trusts him and his decisions allthesame.
Now instead lets say that Gavin made an obscure hack which transferred everyone's BTC to his address and pumped out an 'emergency fix' that everyone should update to ASAP. Of course the code would fork almost immediately and a bad actor would be reduced from the community. Probably in that bad of a scenerio transactions would be rolled back even. Bitcoin would be damaged, but would survive.
---
As an aside, I personally build all of my releases from HEAD. I do some cursory evaluation of the repository, but I've not the time or skill to identify well constructed exploits so my evaluations tend to just be to identify points of likely stability.
Part of the reason I do things this way is that I enjoy it, but another part is that if I stopped trusting the dev team, I would be prepared to look after the value I hold in Bitcoin anyway. Or at least have a fighting chance of doing so.
Who holds the veto power?
That's an implementation detail.
And implementation details are what I'm trying to get from you.
I've already stated that all I have at this point is a neglected thought experiment, but you seem to keep asking for instrumented binaries (ok, and overstatement.)
I tossed off some implementation detail on-the-fly above. Really though, if you cannot rather effortlessly envision at least the possibility of implementing 'veto' in a Bitcoin-like crypto-currency solution, and even a workable skeletal framework, it is somewhat pointless to try to enlighten you much further on this particular aspect of things.
) make MultiBit "speak" through Tor?
