NUT-XX: Get quotes by pubkeys

[callebtc]

Implementations

• CDK: NUT-XX: Mint Quote Lookup by Public Key cdk#1834
• Nutshell:
• Cashu-TS: feat: get locked mint quotes by pubkey cashu-ts#782

supersedes #329
Get NUT-20 quotes by pubkeys. Requires signatures to prove possession of the corresponding private keys.

[robwoodgate]

The signature scheme is a bit worrying, but otherwise just some nit/questions for clarity.

[TheMhv]

This needs a new NUT number, NUT-29 is already defined in NUT-29: Batched Minting

[thesimplekid]

Generally we us XX and just define before merge

[TheMhv]

This needs a new NUT number, NUT-29 is already defined in NUT-29: Batched Minting

Same thing here

[a1denvalu3]

I've opened a PR with the updated signature logic and test vectors here: #363

[robwoodgate]

I've opened a PR with the updated signature logic and test vectors here: #363

I support @a1denvalu3 's approach in #363 - using a timestamp also allows a mint to prevent reuse of the signature after xx minutes too.

It would be even better with a domain prefix, in case a similar scheme is used later on elsewhere:

SHA-256( b"Cashu_NUTXX_QUOTE_v1" || pubkey || timestamp || mint_pubkey )

But with a timestamp max age specified, the reuse window would be minimal in any case.

[c03rad0r]

Thanks for opening this — it's great to see this direction being taken seriously. I'm building an ESP32-based captive portal (TollGate) that provides WiFi access in exchange for ecash payments. My use case: a mining proxy on the ESP32 connects to a hashpool translator via SV1 stratum. The translator mints ehash tokens for the miner's locking pubkey and currently pushes them downstream via a custom mining.token notification.

This NUT ("Get quotes by pubkeys") would let me eliminate the translator middleman — the ESP32 could directly query the mint for quotes attributed to its pubkey, receive tokens without the push notification hack. This is especially important for resource-constrained devices where running a full translator is impractical.

The domain-separated signature scheme in #363 (timestamp + mint pubkey) looks solid. I'm really looking forward to using this functionality — happy to test with my ESP32 implementation once the spec stabilizes.

[TheMhv]

How it's going?

[robwoodgate]

To hopefully move this forward, I've proposed some amendments in the PR below, which gives us time-bounded replay protection. It is intended to be merged into this PR.

• NUT-XX: replay-protect pubkey quote lookup signatures #391

[robwoodgate]

ACK. LGTM

[robwoodgate]

@ye0man - this looks ready for implementations to build on it

[TheMhv]

This still vulnerable by replay attacks, why removed timestamp field from signed hash?

[callebtc]

This still vulnerable by replay attacks, why removed timestamp field from signed hash?

replay can't be fully prevented without a mint state or perfectly synchronized clocks (i.e. time windows to compensate), so we dropped it

[callebtc]

ACK

[TheMhv]

replay can't be fully prevented without a mint state or perfectly synchronized clocks (i.e. time windows to compensate), so we dropped it

To prevent replay attack, we can make a request before everything to setup some nonce that can be used for validate the mint_quote request.

I suggested it before:
#341 (review)

[robwoodgate]

Presumably, each quote will be the shape specified for the method it represents? So maybe a better wording is something like:

Suggested change

	Where `MintQuoteResponse` is the quote response type defined in [NUT-04][04].
	Where `MintQuoteResponse` is the quote response type defined in [NUT-04][04], or an extension of it based on the method the quote relates to.

[robwoodgate]

Do we NEED a {method} now quotes have method in their structs (#387)?

The endpoint could return quotes for ANY method?

Suggested change

	To query quotes assigned to a public key, the wallet makes a `POST /v1/mint/quote/{method}/pubkey` request.
	To query quotes assigned to a public key, the wallet makes a `POST /v1/mint/quote/pubkey` request.

[TheMhv]

IMO we don't need to separate those request.
Concept ACK for this suggestion

[thesimplekid]

I think we should keep it. It is more inline with batch minting and the responses are still different shapes so I would prefer to return the uniform response of a list of one response type.