And if they started isolated from the main group, for whatever reason?
There are so many ways this can happen, the protocol must be able to recover from this position, otherwise you'll end up like Stellar... frantically searching for a new consensus algorithm while they run one validating node, because they cannot handle forks.
If they start not connected to the main group they can not make transactions for a 2 simple reasons, there are no transactions for them to process because no one has any assets to send, and if anyone does have any assets to send, the initial set of allowed counter-signers isn't present because they are on the main group.
Blocks are votes (sybil proof votes at that) in a very real sense. New blocks added to a chain are a vote for that chain, plain and simple. Chains with the most votes win.
A block is 1 persons vote, the miner who made it. There can not be a majority in a set of 1, and I can come and change that "vote" at any time providing I produce a block(s) with a greater amount of work done.
In fact, POW is a very robust solution to this problem, able to handle up to 50% byzantine failures, which is the highest I know of. In this thread you state that eMunie is capable of resolving up to (n/3)-1 failures, which is 33%.
Are you sure? Who is presenting all these Byzantine failures that total 50%? It is proven by people many times smarter than you, I and everyone else here that the limit of true Byzantine tolerance in
any trustless information system is 33%. Are you saying they are wrong? That Satoshi has achieved the equivalent of faster than light travel in information theory?
Bitcoin gives the illusion that it is more tolerant than 33%, but it isn't, because its impossible as it is an asynchronous, anonymous system.
Quite the contrary - the only reason I'm able to present these counter arguments is that I've been down this theoretical ripple a-like road, in a search for my own fast, energy efficient consensus mechanism. I hope to offer you some food for thought before you go to all that effort of implementation.
You can fix a lot of these problems; here I what I suggest:
* Throw away the trust model completely
* Make votes for transactions cost something (either POW, or burn)
* Handle forks
With all due respect, I'm not going to throw away 2 years of work on the say so of someone I've never even spoken to before 3 days ago. This isn't theoretical work, as we've been actively testing this model for failures for 9 months or more now.