Which quantum threat applies to a blockchain signature, which does not, and what the anchor actually defends against.
The threat that does not apply
"Harvest now, decrypt later" does not apply to signatures. It is a threat to encrypted data: an adversary records ciphertext today and decrypts it when a capable machine exists. A signature is public the moment it is made. There is nothing to harvest.
A claim that HNDL threatens a chain's signatures mixes up two different things, and it is visible to any reader who knows the difference.
The threat that does apply, and it is worse
A quantum adversary who can recover a private key from a public key can recover validator keys that signed blocks years ago. With those keys they can produce an alternative history that is internally valid, signed by the same validator set, and rewrite the past. This is the long-range or posterior-corruption attack.
It is worse than the HNDL framing because it does not need the adversary to be present at the time. The keys are already published, in every block header those validators ever sealed.
What the anchor does about it
An adversary holding every classical validator key and no Falcon key can rewrite at most the tail since the last anchor: at most 128 blocks, roughly 70 seconds. Rewriting anything below an anchor changes that anchor's parent hash, which forces the anchor to be reproduced, and reproducing it needs Falcon signatures the adversary does not have.
History below the anchor activation height remains protected by ECDSA alone, permanently. The anchor cannot reach backwards.
Where this sits in the literature
The threat has peer-reviewed treatment: Azouvi, Danezis and Nikolaenko, "Winkle: Foiling Long-Range Attacks in Proof-of-Stake Systems", IACR 2019/1440, published at AFT 2020, pages 189 to 201.
Two things must be said precisely about that citation:
- Winkle does not say "quantum" anywhere. It supports the *threat*, that is long-range attacks
through old compromised keys. The quantum framing is ours.
- Winkle's defence is a different one. It proposes a secondary validation layer in which clients
sign a hash of the previous block. Ours is a validator certificate under the block hash. So the correct sentence is: the threat has peer-reviewed grounding, the defence is our own.
There is a second published defence for the same threat, "Pikachu" (arXiv 2208.05408), which anchors into Bitcoin through Taproot. If you are wondering why we did not simply checkpoint into another chain, that paper is the honest comparison, and the answer is that checkpointing moves your trust to that other chain's liveness and its own signature scheme.
What is not defended
- An adversary who holds the Falcon keys as well. The anchor is a binding on validator behaviour,
not a defence against a compromised validator set.
- Equivocation. Signing two conflicting anchors is not slashable.
- Anything at the account layer. Ordinary accounts on chain 2800 are secp256k1, exactly as on
Ethereum. See Overview.