Align NUT-04 mint quote accounting with amount_paid / amount_issued

[Egge21M]

This updates NUT-04 to make amount_paid and amount_issued the
canonical way to track mint quote accounting, matching the reusable
quote model already used by NUT-25 and NUT-30.

The deprecated state field is kept as an optional compatibility
field for single-use quotes, with derivation rules documented from
amount_paid and amount_issued. This also adds updated_at to mint
quote responses so clients can avoid applying stale quote updates.

Changes:

• Define common amount_paid, amount_issued, and updated_at fields in
  NUT-04 mint quote responses
• Document mintable amount as amount_paid - amount_issued
• Deprecate state while preserving compatibility guidance
• Add stale-update handling guidance using updated_at
• Update NUT-20, NUT-23, NUT-25, NUT-29, and NUT-30 examples/schemas
  to match

[robwoodgate]

The updated_at param is a good idea, both for monotonic state tracking as noted, as well as being potentially useful for tracking stalled or failed payments.

[a1denvalu3]

Agreed.

[robwoodgate]

ACK

[Egge21M]

Chatted with some folks offline. They raised the point that the combination of amount_issued and amount_paid is already enough to allow monotonic state updates (e.g. new_amount_issued + new_amount_paid > old_amount_issued + old_amount_paid). However this is less explicit and mints should not have any issue adding updated_at.

Should I kick it, or keep it?

[robwoodgate]

Chatted with some folks offline. They raised the point that the combination of amount_issued and amount_paid is already enough to allow monotonic state updates (e.g. new_amount_issued + new_amount_paid > old_amount_issued + old_amount_paid). However this is less explicit and mints should not have any issue adding updated_at.

Should I kick it, or keep it?

I think it has utility - whilst the combination does tell you if the state has changed, it doesn't tell you WHEN.

So unless payload size is a concern, it might be more useful than not, esp for consumer apps.

[robwoodgate]

Have implemented this in cashu-ts (cashubtc/cashu-ts#693). The derivation rules round-trip cleanly in both directions, so transition handling is straightforward.

The only wrinkle is how to handle the case when updated_at is absent (any pre-accounting mint). Suggest we add:

Suggested change

Mints **MUST** update `updated_at` whenever `amount_paid` or `amount_issued` changes. Mints **SHOULD** ensure that `updated_at` monotonically increases for each quote, even if multiple updates occur within the same timestamp resolution. Wallets that receive multiple responses for the same quote **MUST NOT** replace locally stored quote data with a response whose `updated_at` is lower than the latest processed value for that quote. Wallets **MUST NOT** decrease locally stored `amount_paid` or `amount_issued` values based on stale responses.

Mints **MUST** update `updated_at` whenever `amount_paid` or `amount_issued` changes. Mints **SHOULD** ensure that `updated_at` monotonically increases for each quote, even if multiple updates occur within the same timestamp resolution. Wallets that receive multiple responses for the same quote **MUST NOT** replace locally stored quote data with a response whose `updated_at` is lower than the latest processed value for that quote. Wallets **MUST NOT** decrease locally stored `amount_paid` or `amount_issued` values based on stale responses, or when the response has no `updated_at` value.