There has been extensive testing and we already have robust error detection and correction, you would know this if you read our recent blog post which covers some of these concerns you mentioned
http://www.blog.emunie.com/Let's say a state actor or rogue ISP decides to shape traffic to fragment the network for an extended period of time. I remember Dan talking about some arbitrary time limit built into the system that was rather short to cover network latency that was not covered by this. If the network becomes fragmented into several different pieces this way, let's say three similar sized groups, what was the reference point governing the "longest chain" so to speak? Is it the group with the highest reputation? And is that reputation derived from averaging the entire group, or can you have just one guy with extremely high reputation making it a consensus of only...one person.
Fork consensus was not discussed enough at all when it's probably the most important part of any platform. Dan kind of brushed it off like forks aren't going to be a problem when they definitely can be, especially with ISP traffic shaping and port blocking out the wazoo nowadays.
Comcast Doesn't Give A F*ckhttps://www.youtube.com/watch?v=KMcny_pixDwPretty sure you already read this. Wait for technical paper if you want more detail. Let's not go in circles.
I remember that post now but wasn't thinking about state actor attacks at the time: (n/3)-1.
Emunie seems trivial for a state actor to destroy completely compared to PoW, PoS, and DPoS. If the state actor comes for PoW, you're just screwed temporarily. If they come for PoS, you're screwed permanently, but they will probably make you rich in the process before it goes down. If they go for DPoS, you won't see it coming, then it just implodes (unless all nodes are non-anonymous NGO or something like Tim Swanson says). If they come for Emunie, the state actor attack doesn't even cost them anything since they already own or indirectly have control over all the infrastructure, then you just get a BSOD screen and it never works again.
The point of reference is (as stated previously) the past endorsements that transaction producers have made, a sub-set of these are the nodes that are allowed to vote on future transactions.
In your scenario, imagine there are 99 nodes in the network, and they are all receiving endorsements constantly so they are all eligible to vote all of the time.
If the network suddenly splits into 3 sets of 33, then no future transaction can gain a majority, as 33 votes is always less than the 50 required, thus the ledger in all 3 groups is never appended to. Those transactions time out and no forks results.
I cant explain it in any simpler terms than this, and if you still believe that there will be forks, well, I dont know what else to write.