Claiming profile not found

[minibits-cash]

There are cases where wallet rotates the nostr keys without sync with the nostr / lnurl server leading to this issue that prevents claiming sats received to a lightning address.

[AttaInsularis]

Preface - how do we got here:

Context is 136

While doing recovery did miss the right way to entry wallet - or complete the process - through clicking 'Complete'. That led to necessity to go through this again.

In order to write this up because didn't know that I'm doing it wrong at that time, having thus no prtscn nor know what the screen look like decided that best way how to report it meaningfully is going yet again with recovery process.

The actual process as can recall it:

Have GOS - main profile with no GP Services (no FCM) and the Private Space with GP S.

The last state of Minibits mint (have no other added) is within PS - here the app was put off with the 'Disable' option from the app properties info menu.
(That's because don't know how precisely the state of wallet is in cooperation with mint vs another instance - I'm not well versed with cashu mints protocol.)

So preemptively freeze this PS instance and installed Minibits (previously uninstalled from main profile after successful first recovery into PS) back to main profile. The one with no GP Services.
Having at that time two Minibits in one phone.
One frozen/Disabled, one clear not yet initialized install.

Did recover with seed, adding mint > processing to the state: choosing from Next interval / Complete.

Like this:

That is all what I needed for the purpose of the process description for the now unrelated issue #136.

As happy with this - just deleted entire Minibits from main profile and Enabled/unfreeze the one in the PS.

And since than for each start have this 'Claiming profile not found' pop up.

Claiming profile not found means that wallet rotated its nostr pubkey without syncing with nostr/lnurl server.

May it be that if the process needs time (how long it takes, what is the trigger, is there any pooling rate to batch this(?) and I did that quite quick - the uninstalling - it may not finish the sync.

Also users may be behind VPN/heavy NATed network/TOR - seen in Amethyst build in Orbot and its quite often recommended because of relays seeing the IP. So that may interfere with the process of this syncing.

If that is an common issue: will it be good if I'm notified in UI about the sync state so can take care of it preemptively (force resync) or wait till it resolve itself by design.

In such state it can't claim sats sent to wallet's lightning address from the lnurl server.

So only receiving from LN now not working but otherwise: sending (cashu/LN) and receiving cashu should work?

Also note that iirc all updates available for the latest downloadable GH .apk are possible to install only after recovery process is completed (I make only seed recovery this time so the fix for wallet backup itself is not necessary).

Can't remember precisely but thinking that I was prompted to install update after completed the recovery that borked my wallet state.

If some logs are collectable and they containing private info as it may be helpful for you to obtain them, let me know, will contact you on the mail so it may be unredacted.

[minibits-cash]

As happy with this - just deleted entire Minibits from main profile and Enabled/unfreeze the one in the PS. And since than for each start have this 'Claiming profile not found' pop up.

I see now.

1. When you did recovery from backup in PS, your wallet generated new nostr keys (they are not part of the backup), but it kept the seed you've entered during the recovery (to make sure both imported ecash + future ecash remain recoverable via mint assisted seed recovery using the same seed).
2. On server side, there is a recovery endpoint, that, when called by the wallet at the end of recovery process, finds previous nostr/lnurl profile of the user using the hash of the seed and updates it with new nostr pubkey. Nwly installed wallet retrieves that way the previous public address and publishes updated nostr profile linking address to new pubkey to nostr relays.
3. Then you hit the bug Wallet has not any keys for the selected unit. #136 after the import, you unistalled from PS and unfroze the other Minibits install with the same seed but other nostr keypair, claim API started to complain, as it requires that all those match

This explains your case, however likely not the other cases I see, however I have now a suspicion it might be possible to screw the recovery process due to unclear UX process (using the back button and not completing it) and achieving the same broken state. Number of cases I see is too low to make it happen during normal wallet usage and is below to attempted recoveries. Will try to simulate.

Also note that iirc all updates available for the latest downloadable GH .apk are possible to install only after recovery process is completed (I make only seed recovery this time so the fix for wallet backup itself is not necessary).

That's a sort of failsafe for now - in the fast pace of development and frequent releases there s a high risk of regressions. Reinstalling the github / play version gets you back to last native release, where recovery is supposed to work in case it would have been broken in next updates. If you want to recover to the latest version, do not uninstall, but do Settings > Developer > Factory reset, that erases wallet state but keeps the latest js code.

If some logs are collectable and they containing private info as it may be helpful for you to obtain them, let me know, will contact you on the mail so it may be unredacted.

For help with tests, you might ping me using the nostr DM (dev[at]minibits.cash) or by email (support[at]minibits.cash) and pass me your sentry id from Settings > Developer. Then if you hit something broken, you might set the log level from ERROR (logs only crashes or serious exceptions with no private data) to INFO or even DEBUG on a test Minibits install and retest the issue. Then turn the log level back to ERROR (or turn off completely in Privacy settings). That way I can access the logs without having any unnecessary link between you and your wallet intended for use.

[AttaInsularis]

it might be possible to screw the recovery process due to unclear UX process (using the back button and not completing it) and achieving the same broken state.

Could it be unnoticed by many because(?) as not having the custom LN addresses/not remembering the old random one (not entered in nostr profile - or if as being it not that obvious it should be changed) user not see any wrongdoing by not completing the process the intended way as the wallet balance is loaded.

He just continues with right wallet balance but new (random) LN address. Doing it the same steps as me just with different devices/profiles.

If user does not moving back and forth like myself they wouldn't notice easily.

Also have custom LN address and many does not (that is why I noticed).

If you want to recover to the latest version, do not uninstall, but do Settings > Developer > Factory reset, that erases wallet state but keeps the latest js code.

True - did that. Recover again. Find all funds (must complete multiple intervals now).

Reconnect all NWC and tested, working well.

For help with tests, you might ping me using the nostr DM (dev[at]minibits.cash) or by email (support[at]minibits.cash) and pass me your sentry id from Settings > Developer. Then if you hit something broken, you might set the log level from ERROR (logs only crashes or serious exceptions with no private data) to INFO or even DEBUG on a test Minibits install and retest the issue. Then turn the log level back to ERROR (or turn off completely in Privacy settings). That way I can access the logs without having any unnecessary link between you and your wallet intended for use.

Awesome! Eventually will do.