Place this anchor correctly among the defences that already exist

We went and read the field instead of asserting into it, and two things in the
README were saying more than the literature supports.

The attack has a name we were not using. It is posterior corruption, also called
the founders' attack, long-range attack, history revision or costless simulation.
Tas, Tse, Gai, Kannan, Maddah-Ali and Yu (arXiv 2207.08392) survey the four known
mitigations: social consensus, key-evolving signatures, verifiable delay
functions, and timestamping onto a proof-of-work chain.

That paper proves an impossibility, and the previous wording here would have read
as if we had stepped around it. We had not, because it says something narrower
than it first appears: slashable safety, which is safety plus the ability to
punish the attacker, needs an external trusted source. Plain safety against
posterior corruption does not, and key-evolving signatures are shown to give it
under an honest majority. This anchor does not claim slashable safety and the
README now says so.

What it does claim is now stated where it is actually strong. Key-evolving
signatures rest on an old key being gone once deleted. A quantum adversary does
not need it to have been kept: QBFT headers carry addresses, but every seal is an
ECDSA signature from which the public key is recoverable, and from that the
private one. Deleting the key buys nothing when the chain reconstructs it. The
certificate under the block hash still has to be forged, and that needs a secret
no amount of computation derives from the chain.

So this is the post-quantum analogue of what key-evolving signatures give
classically, in the setting where their central assumption is void. Narrower than
checkpointing, and borrowing nothing from another chain. Both true at once.

Sources opened and checked, not recalled: arXiv 2207.08392, eprint 2019/1440,
arXiv 2208.05408.

anchor/README.md

@@ -35,10 +35,35 @@ for the same threat, Azouvi and Vukolic, "Pikachu: Securing PoS Blockchains from
 Long-Range Attacks by Checkpointing into Bitcoin PoW using Taproot" (arXiv 2208.05408, 2022),
 checkpoints into Bitcoin's proof of work.
 
-So: the threat has peer-reviewed grounding, and the defence in this repository is ours. Anyone
+### Where this sits among the known defences
-weighing it should weigh it against checkpointing, which is the established answer. The honest
+
-difference is that checkpointing borrows security from somewhere else, and this borrows nothing: the
+The literature calls this attack **posterior corruption**, also known as the founders' attack, the
-guarantee is carried inside the header, by the validators who signed it.
+long-range attack, history revision, or costless simulation. Tas, Tse, Gai, Kannan, Maddah-Ali and
+Yu survey the mitigations in "Bitcoin-Enhanced Proof-of-Stake Security: Possibilities and
+Impossibilities" (arXiv 2207.08392) and count four: social consensus by a trusted committee;
+key-evolving signatures, where validators forget their old keys; verifiable delay functions; and
+timestamping onto an existing proof-of-work chain.
+
+That paper also proves an impossibility, and it deserves to be stated correctly rather than
+paraphrased into something scarier or softer than it is. **Slashable safety**, meaning safety plus the
+ability to punish the attacker, is not achievable by a proof-of-stake chain without an external
+trusted source. Plain safety against posterior corruption is a weaker property, and key-evolving
+signatures are shown to provide it under an honest majority. So the impossibility is not "you cannot
+defend yourself"; it is "you cannot make the attacker pay, on your own."
+
+**This anchor does not claim slashable safety and does not compete with checkpointing on that
+ground.** What it addresses is the case where key-evolving signatures stop working. Their guarantee
+rests on a validator's old key being *gone* once deleted. Against an adversary with a
+cryptographically relevant quantum computer, an old secp256k1 key does not need to have been kept or
+stolen. QBFT headers carry validator addresses rather than public keys, but every seal a validator
+ever wrote is an ECDSA signature from which its public key can be recovered, and those seals are in
+the chain forever. From the public key, a quantum adversary derives the private one. Deleting the
+private key buys nothing, because the chain reconstructs it. The certificate under the block hash is what still has to be forged, and forging it requires
+a secret the adversary cannot derive.
+
+Put plainly: this is the post-quantum analogue of what key-evolving signatures give classically, for
+the setting in which their central assumption no longer holds. It is narrower than checkpointing and
+it borrows nothing from another chain, and both of those are true at the same time.
 
 ---