> Yes. To elaborate, for users who don't have any software already installed, this would be a social process of asking many other people/sources what the correct software is. For users who already have correct software already installed, either that correct software has been running recently enough and can generate its own checkpoint, or that software was offline for long enough that it needs a checkpoint, but it can help substantially automate the process of validating a checkpoint and if it cannot validate it, the user should fall back to a similar process of social discovery to determine what the correct checkpoint/update is.

> Do you view the idea of asking many untrusted and/or trusted people/entities what the correct checkpoint is, as not decentralized? Or not sufficiently decentralized?

I'll allow that this falls on a spectrum of decentralization and is definitely more decentralized than "not decentralized at all".

Whether it's "sufficiently decentralized" is a difficult question for two reasons:

1. Maybe you have some formal algorithm for social discovery that you haven't presented here, but without that, it's quite difficult to speculate how it would play out.

2. From the way you're describing this, you're not relying on a formal algorithm, but on a reliable, diverse network. Maybe you're aware that computer networks are inherently unreliable, so you're getting around this by not using a computer network: for example, making a phone call to get a checkpoint hash from someone you trust. There's a lot of human elements here, and humans are unpredictable.

My gut feel is that no, it's not sufficiently decentralized, at least not in a way that presents any real advantages over simply trusting the network, but something like a PGP web of trust[1] could make this more reliable--it's hard to say without fleshing this plan out more.

The two claims I'm willing to confidently make here are:

1. As far as I can tell, you're not proposing an automated way to bootstrap trust OR consensus here, and without this, it's going to be both slow, and prone to the introduction of human error.

2. This system is inherently less decentralized AND less secure than PoW. Verifying a blockchain via PoW doesn't require trust (or put another way, you trust the math, not the nodes you're connected to), so there isn't a need to bootstrap trust. I don't know how PoS will play out, but I do know how PoW will play out in the situations described by Poestra. PoS may work out in practice: I genuinely hope it does, because there would be significant upsides! But I'm not confident that PoS will work out, and I am confident that PoW will.

> > The other key point I think we disagree on is that you seem to think that it's possible to verify that time has elapsed between block validations in PoS. Is that a fair statement of your opinion?

> The question isn't clear enough to me. I think what I can say about that is, given that you have two time anchors (eg one in the past, the checkpoint, and one in the present, your own computer's clock), its possible to ensure that only a certain number of blocks can validly be added between those two time anchors, to a high degree of statistical probability.

> But maybe you could clarify the question?

Okay, given this explanation, I think this basically falls back to your system of bootstrapping trust. Yes, if you can trust the checkpoints, you can trust the times between them. So this disagreement basically collapses back to the first disagreement: I would say that the reliability of the elapsed time between checkpoints is only as valid as the reliability of the checkpoints, and I am not confident in the reliability of the checkpoints.

You did claim earlier that all PoS implementations have elapsed time between blocks, and I'm still mystified as to how you're claiming this is enforced.

[1] https://www.linux.com/training-tutorials/pgp-web-trust-core-...