post-melt.rst (9695B)
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 Since protocol **v45**, the commitment 16 :ref:`TALER_RefreshCommitmentP <TALER_RefreshCommitmentP>` over which 17 ``confirm_sig`` is made includes the ``transfer_pubs``. For 18 compatibility with older clients, the exchange also accepts a 19 ``confirm_sig`` over the commitment without them. 20 21 :http:statuscode:`200 OK`: 22 The request was successful. The response body is `MeltResponse` in this case. 23 :http:statuscode:`400 Bad Request`: 24 The request body is malformed or a parameter is invalid. 25 This response comes with a standard `ErrorDetail` response. 26 Possible error codes include ``TALER_EC_GENERIC_PARAMETER_MALFORMED``, 27 ``TALER_EC_EXCHANGE_GENERIC_CIPHER_MISMATCH``, 28 ``TALER_EC_EXCHANGE_MELT_COIN_EXPIRED_NO_ZOMBIE``, 29 ``TALER_EC_EXCHANGE_MELT_FEES_EXCEED_CONTRIBUTION``, 30 ``TALER_EC_EXCHANGE_REFRESHES_REVEAL_AGE_RESTRICTION_COMMITMENT_INVALID``, or 31 ``TALER_EC_EXCHANGE_REFRESHES_REVEAL_COST_CALCULATION_OVERFLOW``. 32 :http:statuscode:`403 Forbidden`: 33 One of the signatures is invalid. 34 This response comes with a standard `ErrorDetail` response. 35 Possible error codes include 36 ``TALER_EC_EXCHANGE_MELT_COIN_SIGNATURE_INVALID`` or 37 ``TALER_EC_EXCHANGE_DENOMINATION_SIGNATURE_INVALID``. 38 :http:statuscode:`404 Not found`: 39 The exchange does not recognize the denomination key as belonging to the exchange, 40 or the coin is unknown. 41 If the denomination key is unknown, the response will be 42 a `DenominationUnknownMessage`. 43 Possible error codes include 44 ``TALER_EC_EXCHANGE_GENERIC_DENOMINATION_KEY_UNKNOWN`` or 45 ``TALER_EC_EXCHANGE_GENERIC_COIN_UNKNOWN``. 46 :http:statuscode:`409 Conflict`: 47 The operation is not allowed as the coin has insufficient 48 residual value, or because the same public key of the coin has been 49 previously used with a different denomination or a different age 50 commitment. Which case it is can be decided by looking at the error 51 code: ``TALER_EC_EXCHANGE_GENERIC_INSUFFICIENT_FUNDS`` (response is a 52 `MeltForbiddenResponse`), 53 ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY`` 54 (response is a `CoinDenominationConflictError`) or 55 ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_AGE_HASH`` 56 (response is a `CoinAgeCommitmentConflictError`). 57 :http:statuscode:`410 Gone`: 58 The requested denomination key is no longer valid. 59 It is past the expiration or was revoked. The response is a 60 `DenominationGoneMessage`. Clients must evaluate 61 the error code provided to understand which of the 62 cases this is and handle it accordingly. 63 Possible error codes include 64 ``TALER_EC_EXCHANGE_GENERIC_DENOMINATION_EXPIRED`` or 65 ``TALER_EC_EXCHANGE_GENERIC_DENOMINATION_REVOKED``. 66 :http:statuscode:`412 Precondition Failed`: 67 The requested denomination key is not yet valid. 68 It is before the validity start time. The response is a 69 `DenominationGoneMessage` with 70 ``TALER_EC_EXCHANGE_GENERIC_DENOMINATION_VALIDITY_IN_FUTURE``. 71 :http:statuscode:`500 Internal Server Error`: 72 The server experienced an internal error. 73 This response comes with a standard `ErrorDetail` response. 74 Possible error codes include 75 ``TALER_EC_GENERIC_DB_FETCH_FAILED``, 76 ``TALER_EC_GENERIC_DB_INVARIANT_FAILURE``, 77 ``TALER_EC_GENERIC_DB_COMMIT_FAILED``, 78 ``TALER_EC_GENERIC_DB_START_FAILED``, 79 ``TALER_EC_GENERIC_INTERNAL_INVARIANT_FAILURE``, or 80 ``TALER_EC_EXCHANGE_REFRESHES_REVEAL_COST_CALCULATION_OVERFLOW``. 81 :http:statuscode:`503 Service Unavailable`: 82 The exchange currently has no signing keys available. 83 This response comes with a standard `ErrorDetail` response with 84 a code of ``TALER_EC_EXCHANGE_GENERIC_KEYS_MISSING``. 85 86 **Details:** 87 88 .. ts:def:: MeltRequest 89 90 interface MeltRequest { 91 // The old coin's public key 92 old_coin_pub: CoinPublicKey; 93 94 // Hash of the denomination public key of the old coin, 95 // to determine total coin value. 96 old_denom_pub_h: HashCode; 97 98 // The hash of the age-commitment for the old coin. Only present 99 // if the denomination has support for age restriction. 100 old_age_commitment_h?: AgeCommitmentHash; 101 102 // Signature over the old `coin public key <eddsa-coin-pub>` by the denomination. 103 old_denom_sig: DenominationSignature; 104 105 // Amount of the value of the old coin that should be melted as part of 106 // this refresh operation, including melting fee. I.e.: 107 // melting fee of the old coin 108 // + sum over all values of fresh coins 109 // + sum over all withdraw fees for the fresh coins 110 value_with_fee: Amount; 111 112 // @since v27 113 // @deprecated **v32** 114 // Seed from which the nonces for the n*κ coin candidates are derived from. 115 // 116 // @since **v32** 117 // The ``refresh_seed`` is an opaque value to the exchange. 118 // It is provided by the client and is verified with the ``coin_sig`` below. 119 // Its purpose is to ensure that the honest owner of the old coin 120 // can replay a /melt request from data in the coin history, 121 // provided by the exchange and including this value, in case a wallet 122 // was restored into a state prior to the refresh operation. 123 // 124 // The honest owner of the old coin SHOULD use this value 125 // and the old coin's private key to derive kappa many 126 // batch seeds (one for each cut-and-choose candidate) 127 // like this: 128 // 129 // ``bs[] = HKDF(kappa*sizeof(HashCode),`` 130 // ``"refresh-batch-seeds",`` 131 // ``old_coin_priv,`` 132 // ``refresh_seed)`` 133 // 134 // These batch seeds (however constructed) are relevant in the 135 // subsequent reveal step of the cut-and-chose. Each of the 136 // revealed seeds is expanded to a batch of ``n`` transfer private keys 137 // via HKDF: 138 // 139 // ``tp[k][] = HKDF(n*sizeof(HashCode),`` 140 // ``"refresh-transfer-private-keys",`` 141 // ``bs[k])`` 142 // 143 // An individual coin's transfer private key at kappa-index k and 144 // coin index i in the batch is then ``tp[k][i]``. The corresponding 145 // transfer _public_ keys are given in the field ``transfer_pubs``. 146 refresh_seed: HashCode; 147 148 // Master seed for the Clause-Schnorr R-value 149 // creation. Must match the /blinding-prepare request. 150 // Must not have been used in any prior melt request. 151 // Must be present if one of the fresh coin's 152 // denominations is of type Clause-Schnorr. 153 blinding_seed?: BlindingMasterSeed; 154 155 // Array of ``n`` new hash codes of denomination public keys 156 // for the new coins to order. 157 denoms_h: HashCode[]; 158 159 // ``kappa`` arrays of ``n`` entries for blinded coin candidates, 160 // each matching the respective entries in ``denoms_h``. 161 coin_evs: CoinEnvelope[kappa][]; 162 163 // @since **v32** 164 // ``kappa`` arrays of ``n`` entries of transfer public keys each. 165 // These are ephemeral ECDHE keys that allow the owner of a coin 166 // to (re-)obtain the derived coins from a refresh operation, f.e. should 167 // the wallet state be restored from a backup, prior to the refresh operation. 168 transfer_pubs: EddsaPublicKey[kappa][]; 169 170 // Signature by the `coin <coin-priv>` over `TALER_RefreshMeltCoinAffirmationPS`. 171 confirm_sig: EddsaSignature; 172 173 } 174 175 For details about the HKDF used to derive the new coin private keys and 176 the blinding factors from ECDHE between the transfer public keys and 177 the private key of the melted coin, please refer to the 178 implementation in ``libtalerutil``. 179 180 .. ts:def:: MeltResponse 181 182 interface MeltResponse { 183 // Which of the ``kappa`` indices does the client not have to reveal 184 // by calling the ``/reveal-melt`` endpoint. 185 noreveal_index: Integer; 186 187 // Signature of `TALER_RefreshMeltConfirmationPS` whereby the exchange 188 // affirms the successful melt and confirming the ``noreveal_index``. 189 exchange_sig: EddsaSignature; 190 191 // `Public EdDSA key <sign-key-pub>` of the exchange that was used to generate the signature. 192 // Should match one of the exchange's signing keys from ``/keys``. Again given 193 // explicitly as the client might otherwise be confused by clock skew as to 194 // which signing key was used. 195 exchange_pub: EddsaPublicKey; 196 197 } 198 199 .. ts:def:: MeltForbiddenResponse 200 201 interface MeltForbiddenResponse { 202 203 // Must be TALER_EC_EXCHANGE_GENERIC_INSUFFICIENT_FUNDS. 204 // (Since **vCONFLICT**, a conflicting denomination is 205 // reported with a `CoinDenominationConflictError` instead.) 206 code: Integer; 207 208 // A string explaining that the user tried to 209 // double-spend. 210 hint: string; 211 212 // EdDSA public key of a coin being double-spent. 213 coin_pub: EddsaPublicKey; 214 215 // Hash of the public key of the denomination of the coin. 216 h_denom_pub: HashCode; 217 218 }