Sending tokens issued against offline mint are lost in wallet

[BrunswickBTC]

If one attempts to send tokens issued hy a mint that is unreachable, the app will spend tokens and create an ecash uri, but the tokens are unredeemable. The amount shows as spent within the wallet. The app does not appear to show a recovery path.

After this error, if one attempts to send sats from a different mint, the app crashes and shows a "reset required" message.

The mint in question (@callebtc 8333.space:3338) is presently offline and do not know how app behaves after it has become available

== update Mint came back online and sats were recoverable through app

[minibits-cash]

Thanks for reporting and for defensive testing. There is still work to be done on negative test scenarios.

There are one or two interactions with the mint - in case you do have exact denominations to match the amount to send and in case split is needed before send.

Both should fail fast, just after creating draft transaction and before changing any of wallet proofs status, those change only if send tx succeeds. Will need to simulate it.

If you can access the tx detail, would be great to post here the expanded audit trail to see how gar the tx proceeded.

Regarding the recovery - there is not yet one click option. However if you can access the Settings > Backup and Recovery you should be able to export the last backed up proof state in encoded tokens format. To import them, easiest way would for now be to use PC and one of web wallets out there.

Will dig deeper in 2 days, travelling now.

[BrunswickBTC]

Will dig a bit further and get more info, its probably easy to reproduce (disconnect router?)

[minibits-cash]

I reproduced the SEND transaction scenarios when mint is offline.

Please note that I tested the scenario when the wallet device is online, but the mint is down. Your mentioned scenario with router above could invoke that the device is offline, where Minibits has proof of concept in place to support offline SEND and RECEIVE transactions.

• In case the send transaction requires the split of proofs so that they can match the amount to be sent, "split" call to the mint fails, balance does not change as the proofs were not moved. I improved the error messages, as the ones returned from cashu mint library I am using were not readable. This fix will be released after ongoing approval of new native version by Google. This is how the error will be logged in the audit trail visible in transaction detail

• In case the wallet has exact denominations for the transaction to be sent, there is no communication with the mint needed when creating the encoded token to be sent. Therefore, the transaction should correctly pass to the PENDING state and the token to be sent should be shown (to be scanned or copied) or sent to the pre-selected nostr contact. In this case, only subsequent receive transaction should fail for the receiver - I will test this part later. This is how such (normal) SEND transaction should look like event the mint has been offline

I could not acheive the state when recovery of the wallet would be necessary when sending with mint being offline. If you have more inputs or details of such transaction, please post the audit trail here.

Thank you again for your help to improve the wallet!

[BrunswickBTC]

This can probably be closed since the tokens were not lost, but it appears the cashu protocol should more clearly define what happens and what the wallet should do when a token is received against a mint that is offline.

[minibits-cash]

Thanks for update. In recent release I specifically focused on handling the case the target node being offline yet intermediary node keeping the payment unsettled but not failing it. Some LSP do that for connected mobile wallets (hodl invoices, imo quite bad concept from many perspectives).

In that case payment timesout from cashu wallet point of view and the mint subsequently returns state of proofs as pending.

This has not been handled by the wallet before, because cashu-ts library returns only info on spent proofs and throw away info on pending. Wallet trying to use those proofs got failure from mint. If payment finally settled, wallet required recovery to clean spent proofs.

So after patching the lib and rewriting of related code this state is now handled, proofs stay as pending and resolve final state later.

I mean the new handling of proofs might solve as well other lightning payment failure state, possibly reported one or at least help via improved error messages.