commit abc193e19b81d2341eb6a1bf40e7592550f0473d
parent 51cc3553559392d3d782afd20fceb8999a85d3a3
Author: Christian Grothoff <christian@grothoff.org>
Date: Tue, 22 Apr 2025 14:52:35 +0200
-clarify
Diffstat:
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/design-documents/062-pq-refresh.rst b/design-documents/062-pq-refresh.rst
@@ -89,12 +89,12 @@ fresh coins from a dirty coin is as follows:
m[i] = Blind(C2_p[i], b[i], pkD)
return (s, c2_s, C2_p, m)
-Note that the above deriviation will need to be done ``kappa`` times with
-``kappa - 1`` of the signatures ``s`` being checked by the exchange as part of
-the reveal state of the cut-and-choose protocol. Again, each of the ``kappa``
+Note that the above deriviation will need to be done ``κ`` times with
+``κ - 1`` of the signatures ``s`` being checked by the exchange as part of
+the reveal state of the cut-and-choose protocol. Again, each of the ``κ``
values ``r`` is a public value and can be considered as a kind of a commitment
("I'm going to sign this value") by the dirty coin. The actual *secrets* are
-the ``kappa`` signatures ``s`` which need to be disclosed during the
+the ``κ`` signatures ``s`` which need to be disclosed during the
reveal-part of the refresh operation.
@@ -107,16 +107,20 @@ published.
1. **Melting/Commit Phase**:
- - Client chooses a master (public) seed r and derives κ nonces r_1, ... r_κ.
- - Client generates, using RefreshDeriveBatch, κ*n blinded coin planchets
- m[1][1],...,m[1][n],...,m[κ][1],..,m[κ][n] from the nonces
- - Sends dirty coin, r, all m[i][j] and new denom-info pkD[] to the exchange,
- with signature σ_c of the dirty coins' private key over the request.
+ - Client chooses a master (public) seed ``r`` and derives ``κ`` nonces ``r_1, ... r_κ``.
+ - Client generates, using RefreshDeriveBatch, ``κ*n`` blinded coin planchets
+ ``m[1][1],...,m[1][n],...,m[κ][1],...,m[κ][n]`` from the nonces
+ - Sends dirty coin public key ``Cp``, seed ``r``, all ``m[i][j]`` and
+ fresh coin denomination selections ``pkD[1],...pkD[n]`` to the exchange,
+ with signature ``σ_c`` made with the dirty coins' private key ``cs`` over the request.
- Exchange verifies the request.
- - Exchange calculates h_m = H(r, pkD[], m[][], meta, <maybe more>)
- - Exchange chooses γ from 1...κ and signs all m[γ][], resulting in σ[γ][].
- - Exchange persists h_m → (r, γ, pkD[], m[γ][], σ[γ][], σ_c) and
- returns γ to the client.
+ - Exchange calculates ``h_m = H(r, pkD[], m[][], meta, <maybe more>)``
+ - Exchange chooses ``γ`` from ``1...κ`` and signs all ``m[γ][]``,
+ resulting in ``σ[γ][]``. This is done now as the exchange may later
+ have deleted (or lost) its private signing key.
+ - Exchange persists ``h_m → (r, γ, pkD[], m[γ][], σ[γ][], σ_c)``,
+ deducts the cost for the operation from the old coin balance
+ (in the same database transaction) and returns ``γ`` to the client.
2. **Reveal Phase**:
@@ -179,10 +183,10 @@ API endpoints
A new ``/melt`` request is needed, that takes the new `NewMeltRequest` as request
body, see below.
As in the existing melting/commit phase, it invalidates the coin and prepares
-for exchanging of fresh coins. Taler uses a global parameter ``kappa`` for the
+for exchanging of fresh coins. Taler uses a global parameter ``κ`` for the
cut-and-choose component of the protocol, for which this request is the
-commitment. Thus, various arguments are given ``kappa``-times in this step.
-At present ``kappa`` is always 3.
+commitment. Thus, various arguments are given ``κ``-times in this step.
+At present ``κ`` is always 3.
The base URL for ``/melt/``-requests may differ from the main base URL of the
exchange. The exchange MUST return a 307 or 308 redirection to the correct base
@@ -253,12 +257,12 @@ Modified melt request structure:
// denominations is of type Clause-Schnorr.
blinding_seed?: BlindingMasterSeed;
- // ``kappa``` arrays of ``n`` entries for blinded coin candidates,
+ // ``κ``` arrays of ``n`` entries for blinded coin candidates,
// each matching the respective entries in ``denoms_h``.
//
// Note: These are essentially the m_i values in the RefreshDerivePQ
// function.
- coin_evs: CoinEnvelope[kappa][];
+ coin_evs: CoinEnvelope[κ][];
// Signature by the `coin <coin-priv>` over `TALER_RefreshMeltCoinAffirmationPS`.
confirm_sig: CoinSignature;
@@ -285,15 +289,15 @@ TODO: explain /reveal-melt endpoint.
// 2. blinding_seed, if provided, skip otherwise
// 3. denominations in order
// 4. amount_with_fee
- // 5. kappa*n blinded planchet hashes (which include denomination information),
+ // 5. κ*n blinded planchet hashes (which include denomination information),
// depths first: [0..n)[0..n)[0..n)
rc: HashCode;
- // The disclosed kappa-1 signatures by the old coin's private key,
+ // The disclosed κ-1 signatures by the old coin's private key,
// over Hash1a("Refresh", Cp, r, i), where Cp is the melted coin's public key,
// r is the public refresh nonce from the metling step and i runs over the
- // _disclosed_ kappa-1 indices.
- signatures: CoinSignature[kappa-1];
+ // _disclosed_ κ-1 indices.
+ signatures: CoinSignature[κ-1];
// IFF the denomination of the old coin had support for age restriction,
// the client MUST provide the original age commitment, i. e. the
