Will someone zap this note 16 sats? Promise to double it trust me bro.

Fireship is hard to beat, I linked to the part that made me think this. 😂

I wonder if, similar to a domain name service, we could have relays that only accept Outbox model kinds. *asking an outbox only relay* "where do I find the relays this pubkey posts too?". No more centralizing relays.

Side quest: create a bot that announces whenever a *suspected* solo miner finds a block. Do I embark?

This has me delusional thinking this could happen to me if I bought one or two 😂. Even if I bought 1000 of the latest BitaxeNerdQ++, it’d take about 2.3 years. So you’re saying there’s a chance? View quoted note →

@calle ChatGPT (o1) did a great job of summarizing how I go about: redeeming nutzaps, checking failed mint melts, and consolidating old token states. If anyone is curious of how I manage my Nostr Wallet state, check below! I still need to figure out the logic for the PENDING tokens. I haven't implemented ecash sends yet. --- Here’s a high-level summary of how that “spent-check plus cleanup” code works and some things to keep in mind: Combining All Potential Tokens Together You merge tokens from three sources into one array: The existing 7375 token event(s) for that mint (mg.decryptedTokenEvent). Any redeemed nutzap tokens still in local storage (mg.nutzaps). Your local “attempted sends” array (mg.attemptedSends – from sentTokensAttempted in local storage). This means if the user tried to pay an invoice (thus minted some ephemeral “payment”/“remainder” tokens) but crashed/reloaded mid-process, those partial tokens wind up in local storage and get included in this single list. Making an All-In-One checkstate Call You then POST /v1/checkstate with all these tokens at once to see which are “UNSPENT” vs “SPENT.” Anything that actually got redeemed / melted / double-spent on the mint side will come back as SPENT. Anything still recognized by the mint as valid (including ephemeral tokens that never got used in a successful meltdown) will show up as UNSPENT. Consolidating or Re-Saving After the check, you have a unSpentTokens list. You can then do a fresh swap (if needed for re‑denomination or to unify everything into one set of proofs), and finally publish a new 7375 “token event” to store these updated proofs. If some ephemeral tokens from a failed meltdown remain unspent on the mint, they’ll now get properly re‑recorded for the user. If the meltdown actually worked and the tokens were used, they’ll be recognized as SPENT and excluded from the final set. Cleans Up Partial States Because of this step, your user’s final, consolidated set of tokens is always correct even if they half-finished an action the last time around. You also publish a new 7375 event referencing the fresh set and can “delete” older events or ephemeral references. Potential Concurrency or “Double-Spend” Edge Cases If the user tries multiple meltdown attempts for the same tokens rapidly or in different browser tabs, there can be concurrency issues. Generally, your checkstate call will see that some tokens became SPENT and remove them from the final set – so you won’t double-record them in 7375. Just be aware that if the user does weird concurrency things, you could end up repeatedly rewriting events or having multiple partial states. This is somewhat unavoidable if a user truly tries to do “two meltdown calls in parallel,” but your final “cleanup on next load” logic still helps keep them from losing tokens. Overall, your approach of “throw everything together (existing tokens + local nutzap tokens + local attempted-sends tokens) → run a spent check → re‑save or re‑swap anything that’s unspent” is a common and robust pattern. It ensures that if the user interrupts the process, the next time the wallet loads, you gather all old or partially minted tokens, see which are still valid, and store them properly in a single fresh event. That covers the most common fail scenarios.

Google Chrome continues to push getting rid of ad blockers. Updated Chrome yesterday and it, again, disabled uBlockOrigin. They're stopping short of banning the extension because people would seek alternatives. I'm already there. What's your guys' preferred alternative browser?

@PABLOF7z mentioned that no one had bridged a lightning address to their nostr wallet, so I built it out. Here's a demo of it working and verifying it with Olas. Now you can receive lightning payments to your LUD16 address and ecash sent directly to your nostr wallet. A wallet that travels with you all over nostr. None of this would be possible without @calle, Pablo, and everybody else working tirelessly on nostr and cashu. Thank you guys. This is still in early beta, so PLEASE be careful. View quoted note →

Instead of mentioning Cashu - ecash is custodial every post, I think people will still get the idea if you mention it every other post.

Discouraging View quoted note →

Realizing how useful NIP-60/61 are @calle @PABLOF7z. Wanting to use LUD06/16 with this, thoughts?