Sounds right I think, bootstrap poisoning is one attack vector. One way to address this would be to bootstrap to your representative or whoever gave you your wallet code. Presumably if you trust them enough to download and execute a program that manages your private keys, you can trust them to bootstrap you correctly.
Am I right that the majority of this thread (all the talk about storing votes on chain or not) comes down to this exact problem? A bootstrapping node can be fooled with a fork if whoever had the majority vote
at the time of the fork votes differently when this new node is syncing for the first time. That brings up another question: if nodes A and B have all the voting power at block 100, but today at block 500,000 the voting power is owned by nodes C and D -- won't a new bootstrapping node, encountering a fork at block 100, ask for votes from nodes A and B? What if those nodes are so old they are offline forever by now? Or even worse if their private keys have been compromised since block 100, then anyone can trick a bootstrapping node and send them off on a new fork starting at block 100...?
