Who should I check out here no nostr that's developing stuff around nostr with monero? #asknostr #monero

There we go, added Bitcoin SP address type (sp1) derived from your npub as another option instead a direct random derivation of the other address types (bc1q and bc1p) with a random tweak, for those who want fallback chain scanning/processing. Sending to sp1 addresses also works. However, for this nostr signer/wallet, the primary discovery flow is nostr, which also covers silent payments, so it doesn't have chain scanning (maybe some other client/wallet would do this).View quoted note →

Just a random thought to: It's not worth getting frustrated/angry if something goes wrong during development (coding or otherwise), in all of its various forms, as that will at best not help improve things, and at worst might cause even further issues, especially if you're working with other people. Assume the worst, be delighted of success, and be glad issues arise early or mid way so they can be fixed/adjusted =3 (ex: i'm happy when demo days work, and super glad when they don't because it means there was issue that i can fix)

Nostr Silent Payments (NSP) (sorry for the shit quality) Send to random addresses derived from and controlled by the recepient's npub. Receive to random address derived from and controlled by your npub. Bitcoin and other compatible chains (Yes, silent shitcoin sending on nostr). Compatible with most/all wallets (the transacations part), you don't have to use a special wallet to send a transaction (but of course you'd need the client to be able to send No scanning/processing blockchains, an encrypted notification event is sent (by an ephemeral key) to the recepient's user-relay-list, then upon discovery and confirmation it would be saved (the tweak) to a self-encrypted event list. The sender would also have a self-encrypted event list that stores transactions they've sent (just in case). For sending from an NSP wallet, Bitcoin and other UTXO-based won't have trouble as it'll behave like other wallets combining multiple inputs to an output. However, the luxury isn't available for account-based addresses, you have to manually send out one address at a time, and if you receive a token on them but don't have gas, you have to gas up one by one as well (that of course sucks, but that's the system you're dealing with, however, I did add a system to automate adding gas to each of the needed addresses (maybe I should add an automated system as well for the send part... dunno). For silent (?😅) zapping, it'll be a private (another '?😅') zap if you want to do it (slap an a or e tag for the event your zapping), where only the recepient can decrypt the zap and confirm if it's legit to see it in the UI (client handles this). Notification kind: 1604 Records: NIP-78 Any of this good? bad? horrible? Who knows, maybe a lot of funds will be lost because it can easily happen (i accidentally lost a few sats while testing this xD), but hey it's here we can play with it (haven't updated DENOS repo with this yet, will do it later) NIP-NSP link:

Gitea

DNN/docs/NIPS/NIP-NSP.md at main

DNN - A decentralized, Bitcoin-anchored naming system for nostr and the web.

Another pilot, and I think I like this more =3 Fun/Interesting concept

Rabbit medieval Sekiro was not on my bingo card #gaming

Actually... I play around with a stupid idea in the future to help out monero peeps x3View quoted note →

It's nice, though rough (i guess expected from a pilot). If it continues, I hope it delivers neat/good stories in each episode =3

Another filter for web of trust maybe idk: Does you bitcoin derived address have some money in it? Yes: I'll see your posts No: I won't see your posts x3