"network partitioning risk" is an aspect of many issues, such as the Sybil attack. Just because the Sybil attack exists in the Bitcoin ecosystem doesn't mean it's a game stopper.
The same solutions that solve many kinds of bootstrapping problems can easily be employed to stop fragmentation problems. Also, I want attacker chains to be fragmented. Fragmentation isn't always negative.
If my node decides to revert to a chain past a few hours, I want it to stop and manually ask me what chain to follow. This is exactly why checkpoints were added to Bitcoin and checkpoint like systems are employed by many coins. Checkpoints represent human input, manually making a decision. Blockchain is a voting automation system, it is not a replacement for my voice.
This isn't just theory, but practice! Bitcoin Core version 0.8 _broke the bitcoin network_. Humans had to manually pick a chain and manually revert to an older version of software. And yet no apocalypse materialized.
All prior versions before 0.8 were self-inconsistent-- accepting or rejecting some large blocks depending on their own history of orphaning and reorgs which would be different on different nodes-- and would have split all on their own eventually.
The distinction with 0.8 is that it made the maximum block size that a miner would create command-line configurable and larger blocks have a much easier time triggering the pre-0.8 inconsistency.
People originally thought that 0.8 was at fault since this happened a little while after 0.8's release and the first diverged node-pair people looked at were 0.8 vs 0.7. But that belief was mistaken.
> manually revert to an older version of software
Only a few percent of nodes had split there. The vast majority were on the more restrictive fork. I'm not, for example, aware of any exchange that observed a reorg from this.
> If my node decides to revert to a chain past a few hours, I want it to stop and manually ask me what chain to follow. This is exactly why checkpoints were added to Bitcoin
That was not why they were added and they have never had a behavior like that.
Stopping can be acceptable for some uses, but it's not a safe behavior in general and could dramatically exacerbate a network fault.
FWIW, ethereum will not stop in a big reorg. However, ethereum nodes do randomly stop for no reason whatsoever, and businesses have responded by automating blowing away the state of stuck nodes and re-warp syncing it against the network. The effect of this has been to essentially downgrade these exchanges to no-better than SPV security: they'll trust whatever gets mined.
> checkpoint like systems are employed by many coins
I'm not aware of systems like Bitcoin used by other altcoins, I am aware of quite a few where the developers broadcast signatures the rig the consensus which call themselves 'checkpoints' in order to deliberately deceive users about the security properties through an erroneous comparison to bitcoin like the one you're making.
"network partitioning risk" is an aspect of many issues, such as the Sybil attack. Just because the Sybil attack exists in the Bitcoin ecosystem doesn't mean it's a game stopper.
The same solutions that solve many kinds of bootstrapping problems can easily be employed to stop fragmentation problems. Also, I want attacker chains to be fragmented. Fragmentation isn't always negative.
If my node decides to revert to a chain past a few hours, I want it to stop and manually ask me what chain to follow. This is exactly why checkpoints were added to Bitcoin and checkpoint like systems are employed by many coins. Checkpoints represent human input, manually making a decision. Blockchain is a voting automation system, it is not a replacement for my voice.
This isn't just theory, but practice! Bitcoin Core version 0.8 _broke the bitcoin network_. Humans had to manually pick a chain and manually revert to an older version of software. And yet no apocalypse materialized.