[Mint] Check for duplicate blinding factor within existing promises when initiating a split

[minibits-cash]

Related wallet issue: minibits-cash/minibits_wallet#28

Summary:
If wallet send blinded message for a split that has been generated using the same secret as before, mint spends the ecash and fails to deliver new promises, leading to ecash lost from walet POV.

This situation can happen on wallet side for various reasons after implementing the deterministic secrets which uses incremental recovery indexes to derive secrets. In case wallet does not increment the index, the blinded message is generated using secret generated using the same derivation path as before.

Wallet may fail to increment the index because of a bug, or, as in referenced wallet issue, because of external failures, that can not be fully prevented.

Proposed fix:
Mint needs to check there is not existing promise generated from blinded message with the same blinding factor before it spends and not let it fail too late on DB integrity constraint.

[callebtc]

Still looking into this. The cost for doing this validation in the mint is very high compared to other checks and thus I'm unsure if it should exist or not.

[minibits-cash]

I decreased the rate of occurrence of the issue in minibits by increasing and persisting recovery counters before initiating a swap (and recoverying not delivered ecash in case swap succeeds on mint side but fails to reach the wallet).

However this is only one situation where this happens. Another common situation is that the user does not fully complete the recovery (so mint keeps unrecovered promises) or forgets to recover whole mint.

As the result is fatal we should find a way to fix it, otherwise the whole cost-benefit of detsec does not work. If the check requires search over promises table, some index should make it viable at least until we figure out better overall concept.

[callebtc]

As the result is fatal we should find a way to fix it, otherwise the whole cost-benefit of detsec does not work. If the check requires search over promises table, some index should make it viable at least until we figure out better overall concept.

I think you have a point here.

[ngutech21]

The general issue is that not all Rest-endpoints in the cashu api are idempotent. I proposed a simple solution here: cashubtc/nuts#64

https://restfulapi.net/idempotent-rest-apis/

[callebtc]

The general issue is that not all Rest-endpoints in the cashu api are idempotent.

I think It's not only that. You can request a signature on the same blinded message B_ twice in two different requests and you would run into the same issue as described. @ngutech21 would you agree?

Being able to cache request-response pairs would make sense for spotty internet connections. I'm not sure if that would be more fit for a middleware or another type of layer around the protocol though.

[callebtc]

This issue is already fixed in Nutshell, see here. Fix for LNbits mint still in progress.

[ngutech21]

The general issue is that not all Rest-endpoints in the cashu api are idempotent.

I think It's not only that. You can request a signature on the same blinded message B_ twice in two different requests and you would run into the same issue as described. @ngutech21 would you agree?

If you provide the same idempotencykey for both requests, this will not result in an error. This is the responsibility of the wallet.

Being able to cache request-response pairs would make sense for spotty internet connections. I'm not sure if that would be more fit for a middleware or another type of layer around the protocol though.

This sounds like an implementation detail to me. I think we should add idempotencykeys to all Rest-Endpoints that have this issue. It doesn't break the api because it's just a header.

[minibits-cash]

Should be now fixed in v0.4.2 of lnbits cashu extension.
https://github.com/lnbits/cashu/blob/cce710007bef1c4c89640495ba33db0f54a18fdc/lib/cashu/mint/verification.py#L122C13-L122C79