> If we must choose a real world implementation, I would choose Bitcoin Cash, not because it's the best but because it's the simplest. Unfortunately I don't kn

> If we must choose a real world implementation, I would choose Bitcoin Cash, not because it's the best but because it's the simplest. Unfortunately I don't know enough about the differences between bitcoin cash and bitcoin to be helpful there. I didn't think there was any substantial difference with respect to the consensus mechanism. Is there a big difference? > agreeing to an implementation is not the same as trusting an entity about the state of the blockchain I believe I did address that. But we're also addressing this in a separate comment as well. The way you state that I certainly agree - agreeing amongst many peers (to anything) is not the same as trusting a single entity (about anything). However, I think I made it clear that I'm not suggesting trusting a single centralized entity. Must I repeat the stuff about verifying the checkpoint with many peers and having a codebase reviewed by many reviewers? > you're agreeing to a protocol, not to the state of the blockchain Agreeing to a protocol is the same as agreeing to the state of the blockchain. A protocol will choose one chain to follow. It does this with various types of rules. If you change the rules, you might change the chain. A checkpoint is just yet another rule that becomes part of the protocol. This is why if you download a malicious piece of cryptocurrency software, it can make you follow whatever chain it wants you to follow. A checkpoint is far more constrained than a software update. It can't change most of the rules, just one: which chain to follow if only some chains contain the indicated block. > connect with your old client, and you'll see the Bitcoin Cash chain Given that Segwit was a soft fork, you'd still see the Bitcoin chain, not Bitcoin Cash. Not sure about Ethereum Classic. > I don't think you can reasonably argue that these chains are malicious chains. I agree. But the user still needs a way to answer that question. Most users will choose based on who they want to interact with. Only users that have really deep knowledge will choose based on the code itself. This seems to be what you're saying here: > I don't think it's actually true that the chains don't tell you which chain is Bitcoin or which chain is Ethereum, in a "social adoption" sense. On the contrary, the chains give you a very good idea of how much adoption each chain has received. I believe you're right. It sounds like you're point is that the user will usually want to follow the heaviest chain, and so my point about dangerous soft forks is moot. I'll concede that's a reasonable point. > the entire vulnerability here is based on the unreliable-ness of the network. You don't know how many providers you're connecting to. This is why it's a problem that your proposal requires diverse connections to the network. But this is always true in any decentralized network. That's the whole issue around sybil attacks - you can't prove that two identities are actually distinct. All decentralized networks require diverse connections to the network. > PoW solutions only require that you be connected to one valid node Yes, I agree. But this comes back to the original software download. If 7 sources have malicious software, and 1 sources has the honest software, how do you know which one is honest? Its the same problem. The only difference is that in proof of work, as long as there's no required software updates, you can come back online after an arbitrary period of time and find the honest chain, whereas in PoS there is a horizon after which you need to download new data (the checkpoint). Do you agree that's the salient difference - how long you can go away before you'll have to download and verify updated data to identify the correct chain? > the hardest problem isn't proving consensus, it's achieving consensus in the first place. Checkpoints are a very slow way to do this, and indeed relaxing the requirement for on-chain provability allows us to achieve consensus a lot faster. I don't understand what you're referring to about "relaxing the requirement for on-chain provability". Could you elaborate? > <5 second finality with millions of nodes Avalanche sounds a bit like Nano. > allow consensus even when >50% of nodes are malicious This sounds dubious. I remember Charlie Lee once said "If a blockchain can't be 51% attacked, its centralized and permissioned".