@Minibits
₿ ecash and lightning wallet for instant, low-cost and private value transfers.
Relays (3)
- wss://relay.damus.io/ – read & write
- wss://relay.minibits.cash/ – read & write
- wss://relay.primal.net/ – read & write
Recent Notes
I had a lightning transaction 'complete' between nostr:nprofile1qqstxwlea9ah3u6kjjszu6a7lrnhqkfh8eptp2z6v0e9558tlkkl2rg20d4vz and nostr:nprofile1qqs0y3tvskgs9gpgxxu5ahgz3fmms3rzmxt504qceqtz4a6pdgfwlkg...
Hi is that the same issue we've looked at on telegram?
Hi nostr:nprofile1qqstxwlea9ah3u6kjjszu6a7lrnhqkfh8eptp2z6v0e9558tlkkl2rg20d4vz, I haven't been able to zap in a while and was doing some digging to maybe figure out why. I don't think the SSL direct...
Hi, indeed minibits TLS auto-renewal failed, sorry for the issue, was fixed few days ago. If you see longer term failures on NWC, you might try:
1. Normal payment of a lightning invoice to see if the wallet is operational
2. Recreate and re-add NWC connection to your nostr app and retry.
3. Check if wallet balance in your nostr app is loaded (showing up to your set daily limit). That means that basic NWC connection is working and what fails is lightning payment flow
4. Check if you see transactions with error in the wallet related to failed zaps. If so, dm me their audit trail.
1. Normal payment of a lightning invoice to see if the wallet is operational
2. Recreate and re-add NWC connection to your nostr app and retry.
3. Check if wallet balance in your nostr app is loaded (showing up to your set daily limit). That means that basic NWC connection is working and what fails is lightning payment flow
4. Check if you see transactions with error in the wallet related to failed zaps. If so, dm me their audit trail.
Anyone hear from nostr:nprofile1qqstxwlea9ah3u6kjjszu6a7lrnhqkfh8eptp2z6v0e9558tlkkl2rgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wfjkccte9ekkjmnfvf5hguewvdshx6p0qythwumn8ghj7un9d3shjtnswf5k6ctv...
Relay should be back and accepting connections. Sorry for inconvenience.
1💜1💯1
I know I don't need to do anything, but if I get a notification that I recieved sats, then there is not transaction showing it in the app, then there is some bug.
Agree, not correct. As I've said need to retest.
How do I swap it for fresh ecash? I have no notification that it was paid and don't see anything in the ui saying where I do that.
This is how receiving ecash works - you do not need to do anything.
On my side I see it was received correctly (state changed from pending to completed).
Anyway, I need to retest while pr flow on my side to see if it's a general big or just your wallet getting mad.
On my side I see it was received correctly (state changed from pending to completed).
Anyway, I need to retest while pr flow on my side to see if it's a general big or just your wallet getting mad.
1
I don't understand why that changed when I pasted it was a cashu request
creqApWF0gaNhdGVub3N0cmFheL9ucHJvZmlsZTFxeWQ4d3VtbjhnaGo3dW45ZDNzaGp0bmRkOWh4amNuZnczZWp1Y21wd2Q1ejdxZ2h3YWVoeHczMDlhZXgybXJwM...
I paid the pr. Asi it's ecash, not lightning, the transaction remains in PENDING state on sender side until the receving party swaps it for fresh ecash.
It can be paid mutiple times. Check if you've got those 10 sats.
It can be paid mutiple times. Check if you've got those 10 sats.
❤️1
Minibits now comes with new immersive look and navigation, giving max space to roll over your transactions and contacts.
Few bugfixes made it into this over the air release as well, we won't crash anymore if the mint does not publish any contact (how can you?). Enjoy!
Few bugfixes made it into this over the air release as well, we won't crash anymore if the mint does not publish any contact (how can you?). Enjoy!
66❤️9🚀3🤙3❤2🔥1🧡1
nostr:nprofile1qqstxwlea9ah3u6kjjszu6a7lrnhqkfh8eptp2z6v0e9558tlkkl2rg20d4vz any idea what could be going wrong here?
I can barely zap anymore. Never happened until a few days ago.
https://blossom....
Can you send me the audit trail copied out from tx detail screen?
1
lnbc160n1p49p4yapp56h5q8yexgz8exaj6dh4jrj96rec2p427m43pgj5pnpvrn9f6nq4sdqqcqzzsxqyz5vqrzjqvueefmrckfdwyyu39m0lf24sqzcr9vcrmxrvgfn6empxz7phrjxvrttncqq0lcqqyqqqqlgqqqqqqgq2qsp53avfkzw8rx7yu72q5jxkfhm3wl...
Tried it myself. I got "mint can not return the lightning quote" error (in wisp)
nostr:nprofile1qqstxwlea9ah3u6kjjszu6a7lrnhqkfh8eptp2z6v0e9558tlkkl2rgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wfjkccte9ekkjmnfvf5hguewvdshx6p0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0wsvavr I ...
Was that a cashu payment request or a ln invoice? Normal cashu prs can be paid multiple times, ln invoices not so.
1
Thank you so much!
Is this also on the routstrd side or is this on the routstr-core side?
I see most abusive request sprees with "Bun/1.3.10" in the header (as in the example) so if all those are coming from routstr users, should be the daemon - as I've checked, core is python based.
1🫠1
Hey! Yes. Would love to work with you guys to minimise our requests as much as possible. Both of the server side and on the client side.
Here are the relevant repos:
https://github.com/routstr/rout...
Second issue is, that over the same time a burst of /checkstate calls fires, there is a websocket created, over which many dozens of separate subscriptions are created. This does not hit the rate limits, as it is fired over the single websocket connection, but every subscription hits the database, causing dozens to hundreds selects running in parallel. That's not good even that some db deadlocks caused by that were fixed in nutshell recently:
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.52 | INFO | ('2001:4656:29bd:0:674e:4fb1:18d4:1fa3', 0) - "WebSocket /v1/ws" [accepted]
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.56 | DEBUG | cashu.mint.events.client:add_subscription:190 | Adding subscription 7PXvkPM8gsgHd3xUYayN8Q for filter 0219dee1caafe82eba021a56c53421c0ddba71291a63507c43a3b4aa39ccb67cf0
---- dozens to a hundred of those with the same sub id and different filter - then replied by the mint (until the ban kicks the ip out) --
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.62 | DEBUG | cashu.mint.events.client:_send_msg:174 | Sending websocket message: {"jsonrpc":"2.0","method":"subscribe","params":{"subId":"7PXvkPM8gsgHd3xUYayN8Q","payload":{"Y":"02a11aa6449b30fafa1d272fed391ea80cec6d232c9cfe6ff214d78565e52a7521","state":"UNSPENT","witness":null}}}
It apparently looks like that the wallet implementation fires duplicate both /checkstate and websocket sub recursively for EACH ecash proof, instead of just doing it once and in a single call.
So if you can identify this behavior within your routstr wallet code, fix should be really simple.
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.52 | INFO | ('2001:4656:29bd:0:674e:4fb1:18d4:1fa3', 0) - "WebSocket /v1/ws" [accepted]
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.56 | DEBUG | cashu.mint.events.client:add_subscription:190 | Adding subscription 7PXvkPM8gsgHd3xUYayN8Q for filter 0219dee1caafe82eba021a56c53421c0ddba71291a63507c43a3b4aa39ccb67cf0
---- dozens to a hundred of those with the same sub id and different filter - then replied by the mint (until the ban kicks the ip out) --
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.62 | DEBUG | cashu.mint.events.client:_send_msg:174 | Sending websocket message: {"jsonrpc":"2.0","method":"subscribe","params":{"subId":"7PXvkPM8gsgHd3xUYayN8Q","payload":{"Y":"02a11aa6449b30fafa1d272fed391ea80cec6d232c9cfe6ff214d78565e52a7521","state":"UNSPENT","witness":null}}}
It apparently looks like that the wallet implementation fires duplicate both /checkstate and websocket sub recursively for EACH ecash proof, instead of just doing it once and in a single call.
So if you can identify this behavior within your routstr wallet code, fix should be really simple.
1💜2