Generic concept to handle wallet going offline while waiting for split result

[minibits-cash]

In such a case sent proofs will get spent by mint without the wallet receiving change + new proofs.

This is a generalization of the issue minibits-cash/minibits_wallet#28 that is worth discussion what could be a recovery path and if the protocol can plan for that. This situation will reappear in production because of network / device sudden unavailability during split operation.

[ngutech21]

A common way of fixing this in a REST-Api is using a IdempotencyKey in the http-header:

• the wallet generates a unique ID (e.g. a v4 UUID) and adds it as header to the request
• if the request fails (error 500) or times out the wallet retries the request with the same payload and idempotencykey. It is recommended to bump up the sleep time with an exponential backoff algorithm (https://en.wikipedia.org/wiki/Exponential_backoff)
• the mint checks if it had previously generated blindedmessages for these proofs and idempotency keys and returns them again.
  Here is a good explanation of how the stripe api handles these issues: https://stripe.com/docs/api/idempotent_requests

[minibits-cash]

I understand that this would require the mint to implement support for that (most likely cache responses keyed by idempotency id, return them on repeated request and then have some purging strategy in place). This is not trivial change, ideally should be solved on some api gateway component sitting above the mint business logic implementation. On the other hand, it is a concept that then can be turned on-off for any further PUT/POST apis, not just split resp swap.

As an alternative I would like to propose a concept that would hold on "smart client - dumb server" style that Cashu seems to follow. Idea is to store as-is and to-be recovery indexes (counters) aside and increment the counter itself BEFORE the split (swap) api call is tried. After successfull response, the "in-flight" indexes are deleted and received proofs are added to the wallet.

If response is not received because of intermittent failure (from device, network or app), on next run, wallet automatically executes a recovery for "in-flight" proofs within kept recovery indexes AND clears spent ecash from storage. That way, wallet won't become bricked and will receive missing funds at the same time. Then "in-flight" indexes are deleted.

This concept can not be expanded to other operations then send / receive if any, however it builds on deterministic secrets, which aggrevate the above issue so it smells fair that they help to recover from it :) I mean, it does not require any change to the existing mint's style and architecture.

@callebtc @gandlafbtc what do you think?

[gandlafbtc]

As I was reading the problem, my first hunch was also to leverage the deterministic secrets. The flow you described makes sense to me.