taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 7d2c73ac5aadb6308dcc5be2fe074c82383d0642
parent 04dc8e03d8b80b3e7abc975a4f2f2b3eef6383d8
Author: Christian Grothoff <christian@grothoff.org>
Date:   Tue, 22 Apr 2025 16:12:57 +0200

-typo

Diffstat:
Mdesign-documents/062-pq-refresh.rst | 36++++++++++++++++--------------------
1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/design-documents/062-pq-refresh.rst b/design-documents/062-pq-refresh.rst @@ -191,25 +191,21 @@ basically like this (names might change): 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 ``κ`` for the -cut-and-choose component of the protocol, for which this request is the -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 -URL if this is the case. +A new ``/melt`` request takes a `NewMeltRequest` as request body, see below. +As in the existing melting/commit phase, it updates the old coin balance and +chooses a random ``γ`` for the cut-and-choose protocol. 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 ``κ``-times +in this step. At present ``κ`` is always 3. :http:statuscode:`200 OK`: The request was successful. The response body is `MeltResponse` in this case. :http:statuscode:`403 Forbidden`: - One of the signatures is invalid. + One of the signatures (by the old coin or the denomination signature over + the old coin) is invalid. :http:statuscode:`404 Not found`: The exchange does not recognize the denomination key as belonging to the exchange, - or it has expired. + or it is past the legal expiration time (and thus forgotten entirely). If the denomination key is unknown, the response will be a `DenominationUnknownMessage`. :http:statuscode:`409 Conflict`: @@ -222,9 +218,9 @@ URL if this is the case. The response is `MeltForbiddenResponse` in both cases. :http:statuscode:`410 Gone`: The requested denomination key is not yet or no longer valid. - It either before the validity start, past the expiration or was revoked. The response is a - `DenominationGoneMessage`. Clients must evaluate - the error code provided to understand which of the + It either before the validity start, past the expiration or was revoked. + The response is a `DenominationGoneMessage`. + Clients must evaluate the error code provided to understand which of the cases this is and handle it accordingly. @@ -257,21 +253,21 @@ Modified melt request structure: // for the new coins to order. denoms_h: HashCode[]; - // Seed from which the nonces for the n*κ coin candidates are derived + // Seed from which the nonces for the ``n*κ`` coin candidates are derived // from. refresh_seed: HashCode; // Master seed for the Clause-Schnorr R-value // creation. Must match the /blinding-prepare request. // Must not have been used in any prior melt request. - // Must be present if one of the fresh coin's + // Must be present if and only if one of the fresh coin's // denominations is of type Clause-Schnorr. blinding_seed?: BlindingMasterSeed; - // ``κ``` 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 + // Note: These are essentially the ``m_i`` values in the ``RefreshDerivePQ`` // function. coin_evs: CoinEnvelope[κ][];