Payment request consolidation (and extra fees for non-preferred mints)

[robwoodgate]

Consolidates and Supersedes: #355, #380

• Cashu-TS: feat: nut-18 mint preferences (mp, fr, sm) cashu-ts#683
• CDK: feat: add mints_strict field to payment requests cdk#2007
• Nutshell: feat(core): Updates to nut18 and nut26 payment request nutshell#1059
• Dotnut feat: mint strict flag Kukks/DotNut#37

Summary

Consolidates the two open NUT-18 payment request proposals around mint preferences, strict mint lists, fee reserve signalling, and required mint payment methods.

This PR keeps the existing m mint list as the single mint-list field, and adds small companion fields to clarify how that list should be interpreted.

Changes

• Retains sm (supported_methods) to require that the mint used by the payer supports at least one listed payment method, e.g. bolt11, bolt12, onchain from feat(nut-18, nut-26): add preferred_mints to payment requests #355
• Adds mp (mint_preferred) to signal whether the m mint list is strict or preferred (this is a flip from ms in feat: preferred mints #380):
  • absent / false: receiver only accepts proofs from listed mints
  • true: listed mints are preferred, but other mints may be accepted
• Adds fr (fee_reserve) to signal an additional amount the payer MUST include when paying from a non-preferred mint, to cover potential swap/melt fees
• Updates NUT-26 TLV tags for the new fields
• Adds test vectors covering the combined behaviour

Rationale

There were overlapping proposals for preferred mints and strict mint lists. Instead of introducing a separate preferred mint list, this keeps the request format minimal:

• m remains the mint list
• mp defines whether that list is strict or advisory
• fr gives wallets a way to compensate for extra fees when ignoring the preference
• sm lets receivers express the mint capabilities required for the payment flow

This avoids two competing mint-list fields while covering the three desired behaviours.

[robwoodgate]

@callebtc , @thesimplekid - we have three implementations, can we consider final review / merge please.

cc @ye0man

[KvngMikey]

4 implementations:
cashubtc/nutshell#1059

[robwoodgate]

The only thing I still don't love about this is the mint_strict boolean being true if omitted.

It opens up all kinds of edge case issues as undefined is true but other falsey values are false.

I'd rather default to false on omitted, or if strict is the desirable default, flip the boolean semantic to mint_prefer, where true means the list of mints is a preference and false or omitted means it is strict

What are the thoughts on this?

[thesimplekid]

The only thing I still don't love about this is the mint_strict boolean being true if omitted.

It opens up all kinds of edge case issues as undefined is true but other falsey values are false.

I'd rather default to false on omitted, or if strict is the desirable default, flip the boolean semantic to mint_prefer, where true means the list of mints is a preference and false or omitted means it is strict

What are the thoughts on this?

I agree, I think default true is an anti pattern and we should avoid it.

[robwoodgate]

I agree, I think default true is an anti pattern and we should avoid it.

Agreed. Would you prefer to keep mint_strict and make the default false, or flip the boolean semantics to mint_prefer / mint_suggest or similar?

[thesimplekid]

I agree, I think default true is an anti pattern and we should avoid it.

Agreed. Would you prefer to keep mint_strict and make the default false, or flip the boolean semantics to mint_prefer / mint_suggest or similar?

I would flip the semantics. mint_preferred / mp: absent or false means the existing strict m behavior, true means the m list is advisory/preferred.

[robwoodgate]

I would flip the semantics. mint_preferred / mp: absent or false means the existing strict m behavior, true means the m list is advisory/preferred.

yeah, that's my leaning too. @d4rp4t @a1denvalu3, do you agree?

[KvngMikey]

I would flip the semantics. mint_preferred / mp: absent or false means the existing strict m behavior, true means the m list is advisory/preferred.

i agree with this ...

[robwoodgate]

ms (mint_strict) now replaced with mp (mint_preferred).

This gives the same semantic, but flipped so an omitted value means false (strict).

[robwoodgate]

Cashu-TS updated to use new mp semantic (replacing ms)

[thesimplekid]

cdk updated cashubtc/cdk@7009b0d

[KvngMikey]

Nutshell updated cashubtc/nutshell@11612fe