From 067a57eb872a538ba1b900b2844d4ab5fa6e488a Mon Sep 17 00:00:00 2001 From: Liviu Date: Wed, 12 Aug 2026 11:14:43 +0300 Subject: [PATCH] Say exactly what Winkle supports and what is ours We cite Azouvi, Danezis and Nikolaenko's "Winkle" for the threat this anchor addresses. Today we opened the paper instead of repeating the citation, and two things need saying, because a reader who opens it will notice both. Winkle does not mention quantum adversaries anywhere. It treats old validator keys becoming compromised, by any means. The quantum framing is ours. And Winkle's defence is not this one. It adds a secondary layer of client-based validation in which clients sign a hash of the previously sequenced block. The same authors' later work, Pikachu, checkpoints into Bitcoin instead. Both are established answers to this threat, and a reader weighing our design deserves to be pointed at them rather than left to find them. So the README now says it plainly: the threat has peer-reviewed grounding, the defence in this repository is ours, and the honest difference from checkpointing is that checkpointing borrows security from another chain while this borrows nothing. Citations verified at source, not from memory: eprint.iacr.org/2019/1440, AFT 2020 pp. 189-201; arXiv 2208.05408, 2022. --- anchor/README.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/anchor/README.md b/anchor/README.md index d6934c2..575c85a 100644 --- a/anchor/README.md +++ b/anchor/README.md @@ -22,8 +22,23 @@ The threat it addresses is not "harvest now, decrypt later". A signature is publ to harvest. The threat is **retroactive rewriting**: validator keys recovered later can be used to re-sign old blocks, and a chain whose history is authenticated only by ECDSA cannot distinguish the rewrite from the original. Binding a post-quantum certificate into the hash of every anchored header -means a rewrite must also forge the post-quantum signatures. The reasoning follows Azouvi, Danezis, -Nikolaenko, "Winkle" (IACR 2019/1440, AFT 2020). +means a rewrite must also forge the post-quantum signatures. + +The threat is not ours to claim. It is the long-range attack, and the peer-reviewed treatment is +Azouvi, Danezis and Nikolaenko, "Winkle: Foiling Long-Range Attacks in Proof-of-Stake Systems" +(IACR 2019/1440; AFT 2020, pp. 189-201). Two things should be said plainly about that citation, +because we checked it rather than repeated it. **Winkle does not mention quantum adversaries at +all**: it treats old validator keys becoming compromised, by any means. The quantum framing is +ours. And **Winkle's own defence is not ours**: it adds a secondary layer of client-based +validation, where clients sign a hash of the previously sequenced block. A second published defence +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 +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 +guarantee is carried inside the header, by the validators who signed it. ---