Merge remote-tracking branch 'upstream/main' into cached-responses

00.md

@@ -19,15 +19,15 @@ This document details the notation and models used throughout the specification
 ### Bob (mint)
 
 - `k` private key of mint (one for each amount)
-- `K` public key of mint
-- `Q` promise (blinded signature)
+- `K` public key corresponding to `k`
+- `C_` blind signature (on `B_`)
 
 ### Alice (user)
 
-- `x` random string (secret message), corresponds to point `Y` on curve
-- `r` private key (blinding factor)
-- `T` blinded message
-- `Z` proof (unblinded signature)
+- `x` UTF-8-encoded random string (secret message), corresponds to point `Y = hash_to_curve(x)` on curve
+- `r` blinding factor
+- `B_` blinded message
+- `C` unblinded signature
 
 ### `hash_to_curve(x: bytes) -> curve point Y`
 
@@ -54,7 +54,7 @@ Deterministically maps a message to a public key point on the secp256k1 curve, u
 
 ### `BlindedMessage`
 
-An encrypted ("blinded") secret and an amount is sent from `Alice` to `Bob` for [minting tokens][04] or for [swapping tokens][03]. A `BlindedMessage` is also called an `output`.
+An encrypted ("blinded") secret and an amount is sent from `Alice` to `Bob` for [minting tokens][04] or for [swapping tokens][03]. A `BlindedMessage` is also called an _output_.
 
 ```json
 {
@@ -68,7 +68,7 @@ An encrypted ("blinded") secret and an amount is sent from `Alice` to `Bob` for
 
 ### `BlindSignature`
 
-A `BlindSignature` is sent from `Bob` to `Alice` after [minting tokens][04] or after [swapping tokens][03]. A `BlindSignature` is also called a `promise`.
+A `BlindSignature` is sent from `Bob` to `Alice` after [minting tokens][04] or after [swapping tokens][03]. A `BlindSignature` is also called a _promise_.
 
 ```json
 {
@@ -82,7 +82,7 @@ A `BlindSignature` is sent from `Bob` to `Alice` after [minting tokens][04] or a
 
 ### `Proof`
 
-A `Proof` is also called an input and is generated by `Alice` from a `BlindSignature` it received. An array `[Proof]` is called `Proofs`. `Alice` sends `Proofs` to `Bob` for [melting tokens][05]. [Serialized](#serialization-of-tokens) `Proofs` can also be sent from `Alice` to `Carol`. Upon receiving the token, `Carol` deserializes it and requests a [swap][03] from `Bob` to receive new `Proofs`.
+A `Proof` is also called an _input_ and is generated by `Alice` from a `BlindSignature` it received. An array `[Proof]` is called `Proofs`. `Alice` sends `Proofs` to `Bob` for [melting tokens][05]. [Serialized](#serialization-of-tokens) `Proofs` can also be sent from `Alice` to `Carol`. Upon receiving the token, `Carol` deserializes it and requests a [swap][03] from `Bob` to receive new `Proofs`.
 
 ```json
 {
@@ -256,7 +256,7 @@ The deserialized `base64_token_cbor` is a JSON of the same form as a TokenV4 but
 
 `m` is the mint URL. The mint URL must be stripped of any trailing slashes (`/`). `u` is the currency unit of the token keysets (see [Keysets][01] for supported units), and `d` is an optional text memo from the sender.
 
-`i` is the [short keyset ID][02] of the proofs in `p`, which is an array of `Proof` objects without the `id` field. We extracted the keyset ID `id` from each proof and grouped all proofs by their keyset ID `i` one level above (in `p`).
+`i` is the keyset ID of the proofs in `p`, which is an array of `Proof` objects without the `id` field. We extracted the keyset ID `id` from each proof and grouped all proofs by their keyset ID `i` one level above (in `p`).
 
 Note that all fields of the `bytes` type encode hex strings in the original representation of `Proof`'s.
 

01.md

@@ -10,7 +10,7 @@ This document outlines the exchange of the public keys of the mint `Bob` with th
 
 Wallet user `Alice` receives public keys from mint `Bob` via `GET /v1/keys`. The set of all public keys for a set of amounts is called a _keyset_.
 
-The mint responds only with its `active` keysets. Keyset are `active` if the mint will sign promises with it. The mint will accept tokens from inactive keysets as inputs but will not sign with them for new outputs. The `active` keysets can change over time, for example due to key rotation. A list of all keysets, active and inactive, can be requested separately (see [NUT-02][02]).
+The mint responds only with its `active` keysets. Keyset are `active` if the mint will sign outputs with it. The mint will accept tokens from inactive keysets as inputs but will not sign with them for new outputs. The `active` keysets can change over time, for example due to key rotation. A list of all keysets, active and inactive, can be requested separately (see [NUT-02][02]).
 
 Note that a mint can support multiple keysets at the same time but will only respond with the active keysets on the endpoint `GET /v1/keys`. A wallet can ask for the keys of a specific (active or inactive) keyset via the endpoint `GET /v1/keys/{keyset_id}` (see [NUT-02][02]).