Okay I read your entire post. > A. Users who have been connected to the network all along can't be tricked by any kind of history attack. That was never part

Okay I read your entire post. > A. Users who have been connected to the network all along can't be tricked by any kind of history attack. That was never part of the attack proposed by On Stake and Consensus. I'm not accusing you of not knowing this, and I'm not accusing you of ignoring this, I'm just stating it for completeness. > B. Users who are newly connecting to the network simply need to download the correct software, as they need to do with bitcoin. You've made a pretty important shift here from comparing PoS-to-PoW, to comparing PoS-to-Bitcoin. You're no longer saying, "my system is decentralized", you're now saying "my system is just as decentralized as Bitcoin". That doesn't work: just because Bitcoin relaxes its decentralization in some ways doesn't mean it's okay for other solutions to relax decentralization. In fact, this is one aspect in which Bitcoin isn't decentralized: almost everyone goes to a centralized source, Bitcoin.org, and downloads the binary there. Technical users might verify the hash, but that's still a centralized solution. The only truly decentralized solution that Bitcoin offers is that you can download the source code and verify that it does what it says it does, but very few users have the ability to do that: it's a decentralized solution, but it's not a good decentralized solution. However, Bitcoin's solution is still a better solution than the one you're offering. If I download the source code and have the technical ability to do so, I can verify that the source code does what it says it does. There's no centralized trust here: I'm merely agreeing to the terms how the blockchain works. Choosing to accept the updates to the Bitcoin software doesn't imply any consensus about the state of the Bitcoin blockchain. Checkpoints mean something entirely different: that means that I'm trusting the provider of the checkpoint about the state of the blockchain. I'm going to reiterate the difference because it's extremely important: 1. With Bitcoin, there's no trust required if I verify the source code myself. If I review the source code and decide to compile and run it with the latest changes, I'm merely agreeing to the changes in the rules of the blockchain--and in fact I don't have to agree to them (which results in a hard fork: see Bitcoin Cash or Ethereum Classic). I'm not trusting anything about the state of the blockchain. 2. With your proposed "checkpoint" solution, I'm trusting that the source of the checkpoints isn't lying to me about the state of the blockchain. Contrary to your statement, "There is no central source for the checkpoint," there IS a central source for the checkpoint: the server you're downloading from. Remember the problem proposed by Poestra: you receive two different blockchains, and need to figure out which is the real one. All you've done is change the source of the attack slightly: you receive two different source codes containing two different checkpoints and links to two different blockchains, and need to figure out which is the real one. This isn't a fundamental change to the attack, it's the same attack. This is what I meant when I said that getting around your "solution" is trivial. As I said before, checkpoints do exactly nothing to address the problem. All you've done is move some of the block hashes into the source code. Statements like "Everyone who is currently part of the network can validate that the checkpoint is correct" show a fundamental misunderstanding of the problem: with Bitcoin, I don't need to ask anyone which chain is correct. I don't need to ask the community with Bitcoin: your statements about how people can "alert the community" are irrelevant. I don't need to ask the authors with Bitcoin: your statements about things being signed by the authors are irrelevant. The longer chain is correct, period. If I have to ask the network if my checkpoints are valid, that opens up the possibility of the attack proposed by Poestra. Just to reiterate: > Furthermore, when a user does download a checkpoint, some users are going to be careless and download some malicious checkpoint. If they do, but they have honest software, the software can ask their connections if the new checkpoint matches up with them. If it doesn't, it can again raise an alarm to the user. If you downloaded a malicious piece of software, that piece of software will likely connect you to connections that it controls. Even if you introduce your own connections and they provide you with the correct chain information, there's no way for you to verify which source of information is telling you the truth. Again, with PoW this is easy: the longer chain is the real chain. With PoS, the longer chain could be manufactured: you still have not responded to my statement, "Show me a single mechanism in existence that can allow me to look at two blockchains and reject one based on the fact that the blocks were mined too quickly. Hint: it exists, but you're not going to like what it is!" > For a person with an old version of the software to get a malicious checkpoint without an automatic alarm being raised [...] they would have to be eclipsed by the attacker (connected to only attacker nodes) No, because even if they connect to some valid nodes, their software with the malicious checkpoint would identify the valid chain as malicious. > For a person with an old version of the software to get a malicious checkpoint without an automatic alarm being raised [...] the attacker must also have a way to sign the release (of the checkpoint) with the authors' signatures (which the software should also automatically check) The authors are a centralized entity. > For a person with an old version of the software to get a malicious checkpoint without an automatic alarm being raised [...] and the attacker must have accumulated enough minting power (eg in old keys bought from people who have drained those addresses already) since the software last left the chain. That's true, but you've literally proposed one way that could happen. There are other ways this could happen, which are proposed by Poestra. Now, remember when I said you didn't understand the attack proposed by Poestra, and you took that as an insult? Remember how you said that I didn't understand your solution? I've read your post, and it added nothing to my understanding--I did understand your solution before. Does that mean you were insulting me? I'm not going to take it as an insult because that's pointless: all I'm saying is that let's keep this on the level of respectful disagreement and not take disagreement as insult. > For a new entrant to the system, there is a higher risk, but it is no higher than with Bitcoin. The new entrant must find and install the right software somehow, on a machine that isn't compromised. This is a true statement about Bitcoin, but it isn't a true statement about Proof of Work. Bitcoin Cash software from ten years ago can still detect a sybil attack on the Bitcoin Cash chain as long as you connect to one valid node. Again the mistake you're making is that with Bitcoin, the software only encodes agreement to changes to the protocol, whereas in your proposed solution, your checkpoints encode changes trust in changes to the blockchain. This is not "higher risk, but [...] no higher than with Bitcoin". It's a significantly higher risk than with Bitcoin. What you're alluding to here is a real problem, which is how to reach consensus on changes to the protocol. I don't know of a good solution to that problem: certainly Bitcoin Cash's "never change the protocol" solution isn't a good solution. Probably the best solution I know of is Polkadot's on-chain governance, but while Polkadot is PoS, there's no reason on-chain governance couldn't be implemented in a PoW system. And I'm not sure on-chain governance actually solves the problem: it encodes an agreement on how updates to the protocol are agreed upon, but there's still nothing preventing a motivated minority from changing their source code and creating a hard fork. > C. Users who have been connected to the network for a time, but left for a period of time, just need to (manually) download and (automatically) verify a checkpoint. > Item C is situtation that differs most from current Bitcoin. There is some additional possibility for an attack there, but it would still be extraordinarily difficult to pull off. In Bitcoin, there is no need to download any new data, and so there is no equivalent attack vector similar to tricking the user into accepting an invalid checkpoint. However, this attack would be very difficult (eclipse, key theft), cost a lot (buying old addresses with no coins currently in them), and has a pretty limited reward potential (only the possibility of attacking returning and new entrants they can eclipse). So yes, it is a trade off. I think its a good trade off to buy higher security against a 51% attack and lower fees. This is why I say I'm not a PoS detractor. I do recognize that there are tradeoffs here. I'm not convinced of your claim that this attack would be very difficult--while I don't know of a time that it has been implemented in practice, a lot of the pieces of the attack have already been implemented in practice. You ultimately turn out to be correct that it's difficult to implement, but I don't think you know that. Certainly Vitalik and a great many other smart researchers are worried about how this could go wrong, and nothing you've said convinces me that your confidence is justified.