Enlighten me then, why is it that when PoS is taking over in Peercoin, and checkpointing is fading out at the same time? I can only form a logical conclusion of PoS don't need checkpointing from my observation.
You aren't addressing the cited flaws in the research paper. Here it is if you fear clicking on the link:
What is wrong with this mechanism for consensus?
On a high level, by tying our stake to (temporarily) sacrificed cryptographic resources, we
are begging the question of consensus on who is in possession of what resources. Proof of
stake advocates attempt to evade this accusation by pointing out that false histories can only
be created by stakeholders, and their power is limited to a short interval of time (the time
when they are the chosen signers) during which they are incentivized not to do so. Therefore
conflicting histories simply will not appear, and we can appeal to synchronicity of the network
to obtain consensus on the one existing history.
The problem with this argument is simple: the “short interval of time” is only short as mea-
sured by the consensus history, which only corresponds to a short interval in real time if there
exists a consensus history. So we are still begging the question.
In fact, if a stakeholder later
irreversibly sells his stake for some resource outside the system (e.g. at an exchange), he no
longer has incentive not to fork the history (or worse, expose his keys and let others fork the
history) at the point in consensus time when he had control.This is a bit abstruse. We can illustrate it with an example. Suppose that at some early
point in consensus time, a single person has the ability to extend history. (For example,
they have control over every key which a new block is required to be signed by.) This may
have happened organically, if this person’s keys were chosen randomly by the stake-choosing
algorithm, but it could also happen if this person tracks down the other keyholders and buys
their keys. This may happen much later in consensus time (and real time), so there is no
reason to believe these keyholders are still incentivized to keep their keys secret. Alternately,
they may have revealed the keys through some honest mistake, the chances of which increase
as time passes, backups are lost, etc.
Now, we have a consensus history and an attacker who is able to fork it at some early time.
To actually replace the entire consensus history, he needs to produce an alternate history,
starting from his fork, which is longer than the existing history. But every block needs a
new random selection of signers, so is this possible? The answer is absolutely yes: we have
been using this word “random”, but in fact we have required consensus on the set of signers
(otherwise forks would trivially happen), so even a random selection must be seeded from
past consensus history.
Therefore, an attacker with enough past signing keys can modify the
history he has direct control over, causing future signer selections to always happen in his
favour. (It is likely he needs to “grind” through many choices of block before he finds one
which lets him keep control of the signer selection. In effect, he has replaced proof-of-stake
with proof-of-work, but a centralized one.)
Further, this ability to control the future selection of stakeholders (and even the
set of stake-holders, by controlling which transactions appear in blocks) has serious consequences.
This
is because even without a deliberate attacker, the signers who extend the history at every point
have an incentive to direct the history toward one in which they have more stake (and there-
fore more reward), which causes the system to trend toward centralization. They may do this
by skewing the stake selection of future blocks, or more insidiously by censoring transactions
which (may eventually) increase the set of stakeholders.
