Which step did not work? We shouldn't give up so quickly no matter the amount.

In any case, there is still the option to recover from seed phrase - in that case wallet with mint's assistance recreates lost ecash.

Please dm me the audit trail from related transaction detail. Thanks!

1. Make sure you run 0.1.9-beta.24 in Developer screen.

2. If restart did not make it, go to Backup > Wallet backup, you should see ecash proofs count.

3. If so copy it somewhere along with seed, do Developer > Factory reset, restart, go to Recovery and paste the backup

Thank you for testing it! There is definitely a room to improve the process.

Will consider to add proofs swap as an option to the backup screen if the number of proofs is above some limit.

Another option is backup to file, but would require more app permissions and dependencies.

Yet thinking of to encrypt the backup to a seed by default so that it is safe to be copied/pasted in transit.

You've executed with a style with what we have now.

This makes perfect sense. As we deal with ecash, I optimized for nostr addresses, so that sending pure ecash works.

But I see that having pure lnaddress contacts should be possible.

Will think of it how to do it without adding too much complexity (I validate contacts against profiles onnostr relays etc...)

Tap "New format" at the bottom for a v4. Should be in avg 30% more efficient.

True, that's why we split the contacts to Private and Public.

Private (default) are wallet addresses you might pay in future. If somebody pays you by sending ecash over nostr, his nostr address is added, or you do that manually (paste, scan, write).

Public are follows by any npub you provide (and honestly, better option to tip them is likely to send a zap from nostr app and pay it from the wallet by deeplink or Nostr wallet connect)

Switch QR to the new v4 format, makes QRs much more readable. It's the default on latest Minibits.

You're right in principle. Ecash lives on device and there is some time needed to reach and process it - it can't compare to full custodial servers.

As well, to see that zap was paid next to the zapped note requires the receiving node to publish so called zap receipt. That takes some more time.

Do you see any error when you try to send to yourself from within the wallet?

Thank you for your suggestions!

Based on early feedback, there is one gotcha:

If you reinstall and enter recovery, you have no chance to get the latest over the air update with the functionality...

Workaround is to not do reinstall but factory reset from developer options - reser keeps the latest version running.

New wallet backup and recovery option in Minibits has just dropped:

You can now export wallet backup that can include ecash, mints, contacts and recent transactions and than import it into another device / after reinstall.

Recovery from seed is sometimes tricky and if you do not deal with outright device loss or full wallet brick, this might become a go-to option how to move Minibits to new device.

Use with few sats only until battle tested. Should bring less headaches for us all then! Released as 0.1.9-beta.18

You mean you linked the same nwc connection string into two Amethyst accounts?

Honestly, do not see the reason on Minibits side why that should be an issue, but not sure how's that from Amethyst perspective.

But you can create multiple NWC connections in #Minibits, so you can try to make different one for each of your nostr profiles and test if zapping will resume to work in both.

Will be glad if you share the result.

Would be a quite change - we are already multi-mint-multi-currency. Doable in fact. What are the use cases you see for this feature?

Get the yesterday's over the air update. There was a bugfix for a recent regression bug that prevented to claim sats coming to lightning address unless wallet restarted. It is now fixed and wallet tries to claim on start, on coming to foreground and then every 60 seconds when actively in use.

Do you see any further wallet error details in transactions?

Lightning node settles every day quite a lot of transactions close to the defined mint limit of 1mio sats without issues.

Last update did a lot of migrations to improve storage reliability. As an unwanted side effect, second restart is sometimes required to recalculate balances.

Minibits ecash lives physically on device, can't be compared to the typical setup of custodial wallets that just connect to super stable server environment.

On mobile devices, nothing is super stable. That's why cashu protocol includes recovery from seed phrase.

Thank you for kind words! Receiving lightning payments does not depend on the wallet state (online or offline) as they are received by the mint's lightning node.

Mint then issues ecash of the same amount that is claimed by the wallet once it becomes online.

There are some optimizations on how often the wallet tries to claim waiting ecash from the mint, but you should get push notification immediately if your device supports them and you can any time force the claim by restarting.

Of that is that, then go to Backup and recovery and press Increase recovery indexes. It will solve the issue.

Please check in the related errored transaction audit trail what was the error detail as stored in error.params.message.

If that's Token already spent, then remove spent ecash tool helps.

I have a bug there that it does not show the result correctly in the modal, but works anyway, will fix that.

If it's something else, dm me the audit trail and we'll sort it out.

I see more cases with spent ecash related to nwc usage. I'm afraid that android might kill the background app nwc process before it fully completes, but this is very difficult to simulate and even device and battery level specific. Will dig into that deeper over time.