Oddbean new post about login | logout https://github.com/nostrability/nostrability/issues/123 @Minibits @asoltys
I'm not sure I understand where the problem lies. That lnurlp url loads for me. Is it just that minibits can't get a payment off to our node?
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.
How are error messages/logs handled in this unhappy path? What does the zapper see? What does the sending wallet see (if anything)? What does the receiving wallet see (if anything)?
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.
Which nostr app are using @au9913 ? Can you confirm if you are using NWC?
Amethyst with nwc
@Vitor Pamplona is there any way Amethyst NWC setup was preventing @au9913 from zapping with @Minibits to @Coinos
My bad Vitor, I changed my address back. It’s on @Coinos again if you need to test. 🤙
FYI: Got a zap from Vitor and a notification on Primal but not on Damus.
It is definitely very spotty. It looks like the invoice and payment request goes to Minibits but nothing happens. Sometimes it takes a long time. Sometimes it just disappears.
That’s a good way to describe it. Maybe related: I’ve tried NWC for zapping with a few different wallets in the past but @Alby is still the most reliable. I wonder why that is especially since Coinos has a relay too.
Minibits also doesn't seem to accept Tor connections.
All my test zaps from minibits via NWC in amethyst are succeeding at the moment. Takes maybe 3 or 4 seconds but haven't had any failures yet.
I tried about 20 zaps between my Minibits and Alby, half of them received a {"result_type":"pay_invoice","error":{"code":"INTERNAL","message":"Lightning payment failed."}} Back from Minibits NWC relay.
At some point, the relay was rejecting any zap from my phone, but accepting all zaps from the emulator.
All these tests with Tor disabled.
When succeeded, the payment took about 12 seconds from submission to the NWC relay to the response from the relay. @Vitor Pamplona is this a tool nostr might benefit from to assess reliability of various LN solutions? “I cant zap someone” comes up constantly
Maybe... But there are so many things that can go wrong that I don't know the tool would test it all.
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.
It says token already spent. But the distance between zaps were around a minute or so. I wasn't stressing the mint.
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.
So, I had a single 100 sat token and was spending 1 sat in each of the 20 payments. Maybe there is a race condition when updating the token?
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'm curious if you have multiple mints configured in Minibits, or just a single mint? I was having issues with zaps failing, and after I consolidated into a single mint the problem seemed to be resolved. I've been sending and receiving zaps via Amethyst NWC successfully ever since.
Just a single mint
Hmmm... Maybe this is an unrelated problem. Or it's the same problem that I've incorrectly attributed to my mint consolidation, although my problem pretty much disappeared as soon as I went to a single mint. A corresponding problem I was having was that about half the time, my transactions weren't showing up in my transaction log even though they were successful. I think Minibits has flagged that as a bug that will be resolved in a future release. Is it only Alby zap sends you're having trouble with, or is it every provider?
Single mints. https://imgs.search.brave.com/7mg_dSAHLG8rVX2T5A-A7mtp6Puwjii48UQlXtZF6zo/rs:fit:860:0:0:0/g:ce/aHR0cHM6Ly9jZG4x/LmJpZ2NvbW1lcmNl/LmNvbS9zZXJ2ZXI0/ODAwL2M5N2M0L3By/b2R1Y3RzLzY5L2lt/YWdlcy80MjEvTWVu/dG9zX01pbnRfTG9v/c2VfQnVsa19XX182/NzcxMy4xNDEwNzM3/MjYyLjE3MS4xNzEu/anBnP2M9Mg
Lol Akshully... If we're being literal, those are individual mints, not single mints. A single mint would be alone, and not with a group of other individuals. 🤓
😄 I would have figured that through osmosis @frphank would have figured out the one true single mint by now https://nostrcheck.me/media/17538dc2a62769d09443f18c37cbe358fab5bbf981173542aa7c5ff171ed77c4/f2b0368c848a7d81e23f98208ea03931ca4877a135dffa3dbf2522339b70e410.webp
Where I live we mint our own money and the Fed is not involved.
@frphank correct. You are also downstream of the Single Mint™️. Your subordinate mint must consider arbitrary debasement episodes from the one true mint. All of your country’s trade happens over the Single Mint rails, and not in bolivars, seashells, or shekels. In meme form: https://image.nostr.build/c0b73147128845fc3b1faed2fd70ffb6997546ea8762544a635ed1a7c8ecb7b3.png
Our exchange rate for US$ can be adjusted on short notice don't worry. It went up ~15% over the past 5 years to accommodate the US$ flood.
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.
Since we’re testing NWC, I zapped a few sats via Damus about an hour ago and they’re still pending (I assume that’s the state according to that icon). https://image.nostr.build/1a761c3a9012f515aea31ae0dc813459376d0752dcd3e122122c527dfd50a597.jpg
