You forget that forks are known to all participants .. once we see you sign two different blocks with the same key we can un-approve you!
AFAIK that's what BM means by auto-voting/auto-kicking ... it's just not implemented yet ..
BTW. I have a second VM running which monitors my missed blocks and activates the backup if necesarry ..
current issues:
- if I just miss 1 block the backup machine goes online and my delegates produce forks
- if the host machine goes down (power supply) also the backup is down ... can fix this with a second dedicated/VM somewhere else once i have the time and a little money earned ..
Your second machine shouldn't monitor the missed blocks. It should monitor the running state of the main machine (is it online? is the client running?).
This is because if you are just checking the missed blocks you might still end up with both backup and the original running and signing blocks. (If the reason for missing block is for example network delay).
you could activate the backup if lost x blocks in a row (for example x=10)
Then it would be activated the most times for the right reasons... It will not be a big deal to miss 10 blocks or so if you already have produced 1000+ blocks. And your delegates will not be in risk for auto-firing because they created to many forks...
This is also wrong. You shouldn't rely on the missed blocks at all. Your backup should check the running state of the actual machine by another means. You should make sure it has stopped and/or it has no network connection at all (this might be extremely tricky).
In the scenario where you have the backup checking for missed blocks:
1 Imagine the reason for missed blocks is temporary network/hardware issue (DDOS, someone torrenting porn, switch failure, process taking too much CPU etc).
2 Imagine your backup starts producing blocks.
3 Imagine 1 is fixed (DDOS stops, porn is downloaded, switch is restarted, process finishes...)
The result will be again 2 running delegates creating forks.