2) The technical elections can be manipulated by the false assumption that large stakes indicate trust.
Any system that doesn't give large balances a proportionally large chance of getting elected will simply encourage large balance holders to split up their balance among multiple addresses. If
everyone does this, the result will be massive waste of blockchain storage. But if
only some people split up their balance, the ones who split up will have an advantage relative to those who don't.
Suppose there are 10,000 honest nodes that control 5 addresses on average. They are all running for notary, and will perform the function faithfully if called to serve. They haven't created more addresses because they don't care enough about getting elected notary to study the mechanics and engage in abnormal transaction patterns to optimize their chances of getting elected. Suppose Eve comes along and decides to run for notary with an intent to abuse the position, e.g. she plans to disappear and black out the network until the timeout expires and a replacement is chosen. Eve runs for notary with 9,950,000 sock puppet addresses. If each address has an equal chance of getting elected to be a notary, then Eve has a 99.5% chance of getting elected by virtue of controlling 99.5% of the addresses on the network; the fact that each of those addresses only contains a few satoshi is simply irrelevant. Worse yet, there is a 99.5% chance that Eve's replacement will be another of her sock puppet addresses, which will itself disappear when elected. Selecting an address Eve doesn't control has one-half of one percent chance of success per hour; the outage will last 200 hours on average.
The above example shows that the chance of getting elected
must be proportional to some scarce resource that is intrinsically hard to create (stake). I chose coins. Here are some alternatives which I found less suitable:
CDD is scarce, but unfortunately it also encourages sybils, for reasons I've discussed elsewhere.
Hashpower is scarce, but BitShares has already publicly promised to avoid protocols incorporating a computational arms race.
Real-world identities are the scarce resource used to prevent sybils in real-life democratic elections ("stuffing the ballot box"), but obviously real-world identities cannot be verified by an arbitrary node.
Every shareholder votes for one or more backup notaries which may only produce a block if the primary notary fails to produce one for a set period of time (1 hour). After this point the backup notary takes over. There can be a robust chain of command based upon votes in the past that can automatically take over.
If a network split has persisted for an hour, you still have a fork. If the first N backup notaries are offline, your outage lasts N hours.
I suggested the same timeout mechanism, though I didn't specify a suggested value for the timeout. Let's call the parameter NOTARY_TIMEOUT = 1 hour. Both your system and mine protect absolutely against forks caused by splits shorter than NOTARY_TIMEOUT. Both systems generate forks after NOTARY_TIMEOUT has elapsed and the "wrong" side of the split elects a new notary. My system has the additional advantage that the small side of "lopsided" splits -- where a large number of online coins end up on the same side -- will slow its block production rate proportionally. Thus, geographically isolated network problems, e.g. a natural disaster that disconnects a single city but leaves most of the Internet intact, will automatically have good failure behavior as long as the isolated area contains a small number of the total online coins -- regardless of whether NOTARY_TIMEOUT expires before connectivity is restored, or which side of the split the current notary is on. Also, under my system, only nodes that are online at the time of the election can run, avoiding the problem of backup nodes that are offline.
I'll address more of your objections in the next post.