To be honest, self hosted Alby is non-custodial setup with all the pros / cons.
I am full pro self custody, but for small amounts and frequent small payments like zaps it currently makes not good trade off.
That's where ecash, once polished, could provide balanced service.
Minibits improving but still in dev. Do not use with more sats etc...
In any case, thanks for your endorsment!
Yeah, the way NWC works on Minibits is that your device where the ecash resides is wake up in the background to pay for a zap you've just tapped.
So it takes few secs on top that are not there in case of fully custodial server-side wallets. Still cool that it kinda works!
I think lnurl spec for lightning addresses states that redirects are not to be supported.
@MinibitsCash nosyr addresses are then intended for payments only, nostr identity serves to send ecash over encrypted nostr messages as an alternative to lightning.
Hotfix is now installed on Minibits mint. Disabled melting error should be gone.
Thanks nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0dehhxarj9ehhsarj9ejx2a30qyg8wumn8ghj7mn0wd68ytnddakj7xph5zr
nostr:nevent1qqsx5lkf5aq8gw4udq9tgfwmgcqvmlz0nscfs8m5zxnleasl7jvqrasppemhxue69uhkummn9ekx7mp0qgs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccrqsqqqqqplv9nc5
Hi! This is generic error, to know the real cause, go into the related transaction detail in the wallet directly, then expand the audit trail. You can dm me a copy to look at.
Minibits mint might show "Melt is disabled" error and fails to send payments over lightning.
Issue is caused by new (perhaps too defensive) protective feaure of mint sofware intended to prevent loss of funds.
Happened third time over 3 days, will be solved by a hotfix, ETA not yet known. Until then I've setup an alert and will restart the mint as necessary.
Sorry for all inconvenience, ecash too much safu.
On chain support for minting / melting is already baked-in to the cashu protocol, but afaik mint software is not ready for that. Once ready, I'll put the support on the roadmap.
Ou of curiosity, what is your usecase when onchain beats lightning for ecash backing?
How to onboard when time is as scarce as bitcoin. Amazing story.
nostr:nevent1qqs0grm2pyr79ss09zrs0c6a7v7qjr9ve9fwxgvez3cq7paafw9feucpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyrpl7uezu6sjd3yldjyxldvcfemhwr3qaffve9fxkkwwcqq6vhh8uqcyqqqqqqgp357ta
Lightning/melting ecash should be back and working. Seems like a newest mint version failsafe kicked on, turning off the lightning to defend the mint. Investigating the exact reason.
Minibits and Coinos have direct lightning channel with plenty of liquidity. From github issue it sounds like lnurl link returned the actual error, could be some temp issue as the link works for me.
Check the linked github issue, error is copied there. In that case it was likely the error shown (and prettified) by nostr client that could not initiate zap sequence.
Vitor, if you zapped from Minibits, check the error detail on the related transaction screen.
Failures are either network, lightning or wallet state itself. Expand the audit trail params to find out.
e.g. I have reports (could not yet simulate on dev device) that transaction did not fully complete in case user fired many zaps at once. Seems like android might supress too heavy background processing - resulting in incorrect wallet state that breaks further zaps until cleared.
Regarding the round trip duration: Minibits can't fully match the latencies of custodial / server side wallets.
When you zap someone with nwc, published event with encrypted command is read by the server but then encrypted again with server key and routed through remote data push message to target device with Minibits wallet.
After wakeup, Minibits asks mint for a mint quote, might need an ecash swap with the mint to prepare the ecash and forwards it to the mint.
The mint settles an invoice, it is then still upon receiver to figure that out and to publish the receipt.
I would say, one should not expect that to match custodial lightning wallet latency.
Wallet issue than. Head to recovery and press Remove spent ecash. It will fix it.
Will need to simulate the issue, for now seems like final cleaning at the end of tx does not complete, preventing further transactions. Lastly tried 10 zaps with killed app in real hurry but dev env / device seem resilient and they all passed along trace-level logging.
Need to try harder.
You're right that a race condition could lead to the same or similar other issues.
Your original 100sats were represented by ^2 set of proofs (ecash notes) at the beginning - 64,32,4. To get 1sat, (let's ignore fee reserve for simplicity) wallet takes 64 proof and swaps it with the mint for 32,16,8,1,1 and uses 1sat proof to settle payment.
For lightning fee reserve, mint retutns unused fees as a fresh ecash back to wallet.
So plenty room to race inside the wallet state or get out of sync with the mint in case of parallel/async processes.
Minibits internally uses synchronous queue for all ecash ops to prevent that + locks during network requests (so it can e.g. recover back sent ecash when mint response won't come at all).
Even technically prevented, I still might have some logical issue leading to race condition but was not so far able to pin it. As it happens much more often with nwc, background procesessing is suspicious to me as well.
Will repeat your exact 20x1sat zaps test case on dev device.
I solved some issues related to hodl-invoices that robosats uses in the past together with another robosats user.
But not sure about overall state, would require to test it.
At first check in dev settings that you run the latest beta27 version. If not, update in Update manager.
Then in related transaction detail, you should see the Retry button. Press it to receive.
Have no control over bitcoinmints, but the mint itself works quite ok (for keeping few sats for your zaps or casual lightning needs, not more than you'd regret over a minute)
From the screenshot it is visible that there is an error when sending one of the zaps.
If you see related transaxtion with error status in the wallet, dm me audit trail from tx detail screen. If you do not see such transaction, try to send few sats to another lightning address (even to yourself) from inside wallet few times to check if any error appears.
NWC on Minibits uses firebase push messages as a data carrier to pass nwc commands to the device when the app is backgrounded or killed.
Those require google play services to be on device, what is usually not the case on graphene.
Do you have push notifications working on your device? Requires Google play services installed.
If so, try to send few sats to some lightning address from the wallet to make sure that wallet is basically operational.
If you get some error, dm me transaction detail - audit trail data.
Thanks to a great nostr:nprofile1qqsvfdfkn2wmy73wr0yhkf065jrzm8705ar4q6clyuhc7jekhqfdh4spypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3samnwvaz7tmjv4kxz7fwdehhxarjd93kstnyv5hs9565hr bc-ur library was much less painful than I expected.
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
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.
Hi, stumbled upon your note. Sorry for troubles. Sats should not be wiped because of the update, but with the latest native update there were migrations when balances did not recalculate.
You should still see non zero number of your ecash in Backup > Wallet backup.
If you'd need any further assistance to recover, dm me
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.
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)
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...)
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
https://image.nostr.build/e382c0ff996acfbe8f441ba28b7ca5a20206d521a1be2cc0bf825f21c8a611cf.jpg
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.
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.
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.
V4 tokens are now the default encoding in Minibits. Fallback to legacy V3 tokens is only in case of older ecash issued with non compatible keyset format.
Oddbean new post about login | logout
Notes by Minibits | export