aere-network/aere-node
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Say exactly what Winkle supports and what is ours

Browse Source 
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.
This commit is contained in:
Liviu 2026-08-12 11:14:43 +03:00
parent 820ae134f7
commit 067a57eb87
1 changed files with 17 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
anchor/README.md
View File

@ -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.
---