commit 97fe58afb2304322ff0a3e94df12371d6e924f37
parent c325787f79390a20c36638a7659cc8ef26666175
Author: Özgür Kesim <oec-taler@kesim.org>
Date: Sat, 12 Apr 2025 13:41:22 +0200
[dd:pq-refresh] remove garbage, add TODOs
Diffstat:
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/design-documents/062-pq-refresh.rst b/design-documents/062-pq-refresh.rst
@@ -81,13 +81,7 @@ the reveal phase.
Database Changes
^^^^^^^^^^^^^^^^
-A new refresh table is going to be needed that incorporates all necessary data
-for the melting and reveal process.
-
-.. sourcecode:: sql
-
- ALTER TABLE refresh_commitments
- ADD COLUMN hash_chain_commitment BYTEA;
+TODO, see withdraw
API endpoints
^^^^^^^^^^^^^^
@@ -217,43 +211,27 @@ The new ``TALER_PQMeltCommitmentPS`` is defined as follows:
Security Analysis
=================
-1. **Quantum Resistance**:
-
- - No reliance on factoring/DLP
- - Hash functions sized for 256-bit quantum security
-
-2. **Unlinkability**:
-
- - Multiple hash layers prevent chain tracing
- - γ-selection maintains cut-and-choose security
-
-3. **Forward Secrecy**:
- - Per-session hash chains prevent mass compromise
+TODO
Drawbacks
=========
-* Increased hash computations (2-3x current operations)
-* Requires cryptographic agility for hash functions
+TODO
Migration Strategy
==================
-1. Phase: Dual protocol support
-2. Phase: Legacy protocol sunset after N years, or when clients stopped using old melt
+TODO
Discussion/Q&A
==============
-- **Q**: Why not use lattice-based crypto?
-- **A**: Hash-based solutions provide maturity and lower implementation risk. We can layer PQ signatures in future iterations.
+TODO
-- **Q**: How does this affect wallet performance?
-- **A**: Benchmarks show 15% increased CPU usage during refresh, offset by eliminating modular exponentiations.
References
==========
-.. [1] RefreshDerivePQ specification (refresh.pdf)
+.. [1] Work by Jonathan Levine et al., TU Eindhoven. Reference be added here once published
