taler-docs

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

post-melt.rst (8007B)


      1 .. http:post:: /melt
      2 
      3   "Melts" a coin.  Invalidates the coins and prepares for exchanging of fresh
      4   coins.  Taler uses a global parameter ``kappa`` for the cut-and-choose
      5   component of the protocol, for which this request is the commitment.  Thus,
      6   various arguments are given ``kappa``-times in this step.  At present ``kappa``
      7   is always 3.
      8 
      9   The base URL for ``/melt/``-requests may differ from the main base URL of the
     10   exchange. The exchange MUST return a 307 or 308 redirection to the correct
     11   base URL if this is the case.
     12 
     13   This endpoint was introduced in this form in protocol **v32**.
     14 
     15   :http:statuscode:`200 OK`:
     16     The request was successful.  The response body is `MeltResponse` in this case.
     17   :http:statuscode:`403 Forbidden`:
     18     One of the signatures is invalid.
     19   :http:statuscode:`404 Not found`:
     20     The exchange does not recognize the denomination key as belonging to the exchange,
     21     or it has expired.
     22     If the denomination key is unknown, the response will be
     23     a `DenominationUnknownMessage`.
     24   :http:statuscode:`409 Conflict`:
     25     The operation is not allowed as the coin has insufficient
     26     residual value, or because the same public key of the coin has been
     27     previously used with a different denomination.  Which case it is
     28     can be decided by looking at the error code
     29     (``TALER_EC_EXCHANGE_GENERIC_INSUFFICIENT_FUNDS`` or
     30     ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``).
     31     The response is `MeltForbiddenResponse` in both cases.
     32   :http:statuscode:`410 Gone`:
     33     The requested denomination key is not yet or no longer valid.
     34     It either before the validity start, past the expiration or was revoked. The response is a
     35     `DenominationGoneMessage`. Clients must evaluate
     36     the error code provided to understand which of the
     37     cases this is and handle it accordingly.
     38 
     39   **Details:**
     40 
     41   .. ts:def:: MeltRequest
     42 
     43     interface MeltRequest {
     44        // The old coin's public key
     45        old_coin_pub: CoinPublicKey;
     46 
     47        // Hash of the denomination public key of the old coin,
     48        // to determine total coin value.
     49        old_denom_pub_h: HashCode;
     50 
     51        // The hash of the age-commitment for the old coin. Only present
     52        // if the denomination has support for age restriction.
     53        old_age_commitment_h?: AgeCommitmentHash;
     54 
     55        // Signature over the old `coin public key <eddsa-coin-pub>` by the denomination.
     56        old_denom_sig: DenominationSignature;
     57 
     58        // Amount of the value of the old coin that should be melted as part of
     59        // this refresh operation, including melting fee.  I.e.:
     60        //        melting fee of the old coin
     61        //      + sum over all values of fresh coins
     62        //      + sum over all withdraw fees for the fresh coins
     63        value_with_fee: Amount;
     64 
     65        // @since v27
     66        // @deprecated **v32**
     67        // Seed from which the nonces for the n*κ coin candidates are derived from.
     68        //
     69        // @since **v32**
     70        // The ``refresh_seed`` is an opaque value to the exchange.
     71        // It is provided by the client and is verified with the ``coin_sig`` below.
     72        // Its purpose is to ensure that the honest owner of the old coin
     73        // can replay a /melt request from data in the coin history,
     74        // provided by the exchange and including this value, in case a wallet
     75        // was restored into a state prior to the refresh operation.
     76        //
     77        // The honest owner of the old coin SHOULD use this value
     78        // and the old coin's private key to derive kappa many
     79        // batch seeds (one for each cut-and-choose candidate)
     80        // like this:
     81        //
     82        //   ``bs[] = HKDF(kappa*sizeof(HashCode),``
     83        //               ``"refresh-batch-seeds",``
     84        //               ``old_coin_priv,``
     85        //               ``refresh_seed)``
     86        //
     87        // These batch seeds (however constructed) are relevant in the
     88        // subsequent reveal step of the cut-and-chose.  Each of the
     89        // revealed seeds is expanded to a batch of ``n`` transfer private keys
     90        // via HKDF:
     91        //
     92        //   ``tp[k][] = HKDF(n*sizeof(HashCode),``
     93        //                  ``"refresh-transfer-private-keys",``
     94        //                  ``bs[k])``
     95        //
     96        // An individual coin's transfer private key at kappa-index k and
     97        // coin index i in the batch is then ``tp[k][i]``.  The corresponding
     98        // transfer _public_ keys are given in the field ``transfer_pubs``.
     99        refresh_seed: HashCode;
    100 
    101        // Master seed for the Clause-Schnorr R-value
    102        // creation. Must match the /blinding-prepare request.
    103        // Must not have been used in any prior melt request.
    104        // Must be present if one of the fresh coin's
    105        // denominations is of type Clause-Schnorr.
    106        blinding_seed?: BlindingMasterSeed;
    107 
    108        // Array of ``n`` new hash codes of denomination public keys
    109        // for the new coins to order.
    110        denoms_h: HashCode[];
    111 
    112        // ``kappa`` arrays of ``n`` entries for blinded coin candidates,
    113        // each matching the respective entries in ``denoms_h``.
    114        coin_evs: CoinEnvelope[kappa][];
    115 
    116        // @since **v32**
    117        // ``kappa`` arrays of ``n`` entries of transfer public keys each.
    118        // These are ephemeral ECDHE keys that allow the owner of a coin
    119        // to (re-)obtain the derived coins from a refresh operation, f.e. should
    120        // the wallet state be restored from a backup, prior to the refresh operation.
    121        transfer_pubs: EddsaPublicKey[kappa][];
    122 
    123        // Signature by the `coin <coin-priv>` over `TALER_RefreshMeltCoinAffirmationPS`.
    124        confirm_sig: EddsaSignature;
    125 
    126     }
    127 
    128   For details about the HKDF used to derive the new coin private keys and
    129   the blinding factors from ECDHE between the transfer public keys and
    130   the private key of the melted coin, please refer to the
    131   implementation in ``libtalerutil``.
    132 
    133   .. ts:def:: MeltResponse
    134 
    135     interface MeltResponse {
    136       // Which of the ``kappa`` indices does the client not have to reveal
    137       // by calling the ``/reveal-melt`` endpoint.
    138       noreveal_index: Integer;
    139 
    140       // Signature of `TALER_RefreshMeltConfirmationPS` whereby the exchange
    141       // affirms the successful melt and confirming the ``noreveal_index``.
    142       exchange_sig: EddsaSignature;
    143 
    144       // `Public EdDSA key <sign-key-pub>` of the exchange that was used to generate the signature.
    145       // Should match one of the exchange's signing keys from ``/keys``.  Again given
    146       // explicitly as the client might otherwise be confused by clock skew as to
    147       // which signing key was used.
    148       exchange_pub: EddsaPublicKey;
    149 
    150       // Base URL to use for operations on the refresh context
    151       // (so the reveal operation).  If not given,
    152       // the base URL is the same as the one used for this request.
    153       // Can be used if the base URL for ``/reveal-melt/`` differs from that
    154       // for ``/melt/``, i.e. for load balancing.  Clients SHOULD
    155       // respect the reveal_base_url if provided.  Any HTTP server
    156       // belonging to an exchange MUST generate a 307 or 308 redirection
    157       // to the correct base URL should a client uses the wrong base
    158       // URL, or if the base URL has changed since the melt.
    159       //
    160       // When melting the same coin twice (technically allowed
    161       // as the response might have been lost on the network),
    162       // the exchange may return different values for the ``reveal_base_url``.
    163       reveal_base_url?: string;
    164 
    165     }
    166 
    167   .. ts:def:: MeltForbiddenResponse
    168 
    169     interface MeltForbiddenResponse {
    170 
    171       // Must be TALER_EC_EXCHANGE_GENERIC_INSUFFICIENT_FUNDS
    172       // or TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY
    173       code: Integer;
    174 
    175       // A string explaining that the user tried to
    176       // double-spend.
    177       hint: string;
    178 
    179       // EdDSA public key of a coin being double-spent.
    180       coin_pub: EddsaPublicKey;
    181 
    182       // Hash of the public key of the denomination of the coin.
    183       h_denom_pub: HashCode;
    184 
    185     }