Minibits crashes unexpectedly

FiliTol commented 11 months ago

Expected behaviour

Minibits is initialized, setup new mints and start exchanging ecash sats.

Actual behaviour

Minibits is initialized and new mints are added. Then it undeterministically crashes. When opened again, the app looks like has never been initalized, therefore causing loss of founds.

minibits-cash commented 11 months ago

Thank you for your report. Please check the Android version of your device (Settings > About phone > Software information) and post it here please.

FiliTol commented 11 months ago

Android version: 14

minibits-cash commented 11 months ago

Hoped to see old android, but that's apparently not the case. I'd need some more help, have not encountered any issies on a14 so I'd kindly ask you:

As you said, you could add mints before crash happens.

Were you able to add some funds afterwards?
What action did you do just before the crash?
Did you changed any of the default settings before (e.g. storage encryption)
Could you try to simulate the crash again from fresh install and check right after the install the random Sentry id in Dev options and post it here? Then, if possible, set the log level to DEBUG before replaying the actions leading to the crash?

Thank you very much for your help.

FiliTol commented 10 months ago

With regards to your questions:

Yes, I was always able to add funds and new mints
Onestly I didn't execute specific patters. Sometimes happened when opening again the app, sometimes happened while the app was already opened in background. As a common denominator, before experiencing that bug I observed that the app freezed and I was always forced to restart the app, then the app crashed and relinitialized.
As far as I remember, I changed the security settings by setting up the encrypt storage and the Biometric authentication.
I didn't manage to recreate the crash yet.

Thanks a lot for what you are developing.

mariaa144 commented 10 months ago

The same thing happened to me. I see funds in "Recovery tool" and "Unspent" but I don't know how to actually recover the proofs. Maybe they aren't being recovered because the mints are missing.

EDIT: Nope, I added the mints and they all are 0 balance with history showing. How can I recover the funds?

minibits-cash commented 10 months ago

To narrow down the library likely causing the crash, could you please answer:

Did you changed any of the default settings before (e.g. storage encryption)
What action did you do just before the crash?
Device and android sdk version
If you'd be able to simulate the crash again, please follow above instructions to provide logs

Regarding the recovery path you have 2 options: If you can access the unspent ecash in the recovery tool but lost your mint balances after the crash, safest option is to copy them as encoded tokens and then receive them one-by-one by pasting. I'd recommend to do it on pc and receive to one of web wallets as its much more convenient. This likely means that the crash corrupted primary app storage that was recreated empty. Recovery tool uses intentionally different storage tech (sqlite)

If you received the ecash after upgrading/installing your wallet to version with recovery seed and you stored your seed BEFORE the crash happened, you could try fresh install and recovery from your mints using the seed. However if you are not sure you fulfill both conditions, recovery from seed may not work or recover only the ecash received after the feature was available.

In your case I do not recommend to use the seed you see now after the crash, as I suspect bug in react-native-keychain library or related storage encryption for the crash and thus your seed might have been regenerated as a result.

Thank you for your help and for trying the wallet

minibits-cash commented 10 months ago

Yet some further details: if you set storage encryption on device with biometric auth support, app intentionally exits if you fail or quit submitting biometric factor (fingerprint). This is to prevent overwriting of encrypted storage. There might be that some devices handle this in different way and implemented app exit is not triggered leading to above issue. So if you did so, please provide details or try to reproduce it on fresh install. Thanks again

mariaa144 commented 10 months ago

I have turned on "Encrypt storage" and "Biometric authentication".
I had just created a Cashu code to share and I was switching to a messenger app
GraphineOS on Pixel6a. Android 14.

I'll see if I can reproduce the issue and let you know how the recovery goes.

mariaa144 commented 10 months ago

I was switching to SimpleX which also prompts for biometric authentication. I did this after creating the Cashu code to share.

minibits-cash commented 10 months ago

I have turned on "Encrypt storage" and "Biometric authentication".

I had just created a Cashu code to share and I was switching to a messenger app

GraphineOS on Pixel6a. Android 14.

I'll see if I can reproduce the issue and let you know how the recovery goes.

Please install over the air update 0.1.5-beta.22 (update pops up after restart or in Settings). It contains fix to correctly exit the app on quit / failed biometric authentication.

For now, this seems to be a regression bug, sorry for inconvenience. Please retest the scenario where you cancel / back the authentication prompt when starting the app with encrypted storage - app should exit immediately.

It might help with the crash as well, because the wallet state storage should not get overwritten / corrupted again, but this requires further testing as I could not reproduce the crash itself on my test devices so far.

As @FiliTol if you encounter the intermittent crash any later, please try to reproduce with turned on logging.

mariaa144 commented 10 months ago

@minibits-cash I tried loading the cashu codes from the recovery section back into Minibits but I got an error. Something to do with the consistency of the database. I missed the screenshot. The funds were never added back into the wallet and now when I try to load the code again it says it is already spent.

mariaa144 commented 10 months ago

This might have been the original error when I tried to redeem the Unspent key:

{"status":"ERROR","error":{"name":"VALIDATION_ERROR","message":"Ecash could not be redeemed.","params":{"caller":"receive","message":"(psycopg2.errors.UniqueViolation) duplicate key value violates unique constraint \"promises_b_b_key\"\nDETAIL:  Key (b_b)=(02bbe4a1c0843c92ad7d80d0ec3fee950e1f0fa0d5dd018892d888c9fc83cf2864) already exists.\n\n[SQL: \n        INSERT INTO cashu.promises\n          (amount, B_b, C_b, id)\n        VALUES (%s, %s, %s, %s)\n        ]\n[parameters: (1, '02bbe4a1c0843c92ad7d80d0ec3fee950e1f0fa0d5dd018892d888c9fc83cf2864', '038ddd8053a6a2d4a26a07aa7c7916ef219c5b185671e7ae152f7d5b204310dff9', '6t3xlkfY3quN')]\n(Background on this error at: http://sqlalche.me/e/13/gkpj)"}}}

mariaa144 commented 10 months ago

I wasn't able to reproduce the initial crash after upgrading to 0.1.5-beta.22.

minibits-cash commented 10 months ago

This might have been the original error when I tried to redeem the Unspent key:

{"status":"ERROR","error":{"name":"VALIDATION_ERROR","message":"Ecash could not be redeemed.","params":{"caller":"receive","message":"(psycopg2.errors.UniqueViolation) duplicate key value violates unique constraint \"promises_b_b_key\"\nDETAIL:  Key (b_b)=(02bbe4a1c0843c92ad7d80d0ec3fee950e1f0fa0d5dd018892d888c9fc83cf2864) already exists.\n\n[SQL: \n        INSERT INTO cashu.promises\n          (amount, B_b, C_b, id)\n        VALUES (%s, %s, %s, %s)\n        ]\n[parameters: (1, '02bbe4a1c0843c92ad7d80d0ec3fee950e1f0fa0d5dd018892d888c9fc83cf2864', '038ddd8053a6a2d4a26a07aa7c7916ef219c5b185671e7ae152f7d5b204310dff9', '6t3xlkfY3quN')]\n(Background on this error at: http://sqlalche.me/e/13/gkpj)"}}}

Please go to Backup and Recovery > Increase recovery indexes and press Increase. Then try to receive one of the unspent tokens that yu did not try before again. If you had a lot of transactions in the wallet to be recovered, press Increase more then once.

Do you try to receive the backed up tokens to fresh new install with new seed (there such issue should not occur) or to the same wallet instance you copied the recovered tokens from (this might be the case)?

Recovery paths will need special guide covering typical scenarios it seems. In general local backup is intended for available wallet bricked due to wallet or mint bug, and intended to be recovered to another wallet. Recovery from seed is then for cases of lost device.

mariaa144 commented 10 months ago

I tried to restore in the wallet which had the crash. I didn't reset with a new seed.

I had three cashu codes in my recovery page. The first was to my mint. That one gave me the error in minibits. The other two I restored on eNuts which worked fine.

The first cashu code is said to be spent, although it isn't showing in my wallet. Luckily it is my mint and not a problem to lose the ecash.

All three of the cashu codes still show up in my recovery page, even though they are all spent already.

What should I do with my minibits wallet at this point? I'm using eNuts in the meantime.

minibits-cash commented 10 months ago

If you run nutshell then you've hit the bug https://github.com/cashubtc/nutshell/issues/381.

The on-device backup is intentionally append-only db, nothing dissappears. As you were able to recover the rest of tokens, the best approach now is to reinstall minibits.

If you want to keep your wallet address (xxx@minibits.cash), you can go to recover lost wallet from seed and use it, it recovers the previous wallet address as well. During the recovery the wallet should ignore the ecash you moved to enuts, because it has been spent in the process. If you don't mind the wallet address stays the same, just use new wallet.

Thanks for throughout testing and your time.

mariaa144 commented 10 months ago

Thank you! I will continue using minibits and letting you know of any issues I have.

minibits-cash / minibits_wallet

Minibits crashes unexpectedly #30

Expected behaviour

Actual behaviour