I have started play around with making builds and testing them for the discord alt. So... "soon" =3

"When you can, send me $1,000" "Why would i send you $1,000?" "Why are you being so cheap?" "What do you mean cheap? $1,000 is a lot" "No it isn't?" See how stupid this convo is? This is why products that utilize the B currency symbol as a measurment for decimals/sats (whatever that BIP was) is a flaw.

I think all clients for all event types with d tag and published_at tag should make it where any edits published shouldn't do created_at:now but rather created_at:previous+1, and should be standard implementation practice, assuming we won't make published_at like created_at and have relays be able to filter based on that. #nostr

Might have read things wrong, but just in case, because what I've read made me go '???': Don't put your scan private key into a third-party scanning server/service... Yes, a publicly derived Bitcoin SP address, a normal Bitcoin address, and Shitcoin addresses, can be derived publicly, and because of this, a leak of any of those private keys would lead back to leaking/compromising your nsec, that's why these derived addresses should be treated as careful as you treat your nsec (the apps/others you're using the nsec on that does these things). If the intended flow of Bitcoin SP is to give a scan private key to a third-party server/service (not your own locally hosted one), then Bitcoin Silent Payments has failed from the start. Thought I'd make this post, and if I'm wrong then I'm happy to learn.View quoted note →

My 2 sats: Protocols designed for mass public use, but not built from the ground up with privacy as a default, should not be expected to provide strong practical privacy at scale. Operational privacy measures can definitely help, but systems that rely on users behaving like highly disciplined privacy engineers forever will inevitably trend toward convenience instead. Most people will not maintain strict UTXO hygiene, identity compartmentalization, wallet separation, or careful metadata practices long term, especially when smoother and more convenient alternatives exist. Even if most apps, wallets, and clients encourage privacy-conscious behavior, users will naturally gravitate toward the few tools that reduce friction and “just work.” This creates a ceiling for privacy in transparent systems like Bitcoin: privacy becomes conditional, behavioral, and fragile rather than automatic and protocol-enforced. Unless Bitcoin undergoes deep protocol-level changes to make strong privacy a default property of the system, similar to, or even stronger than, Monero, which seems unlikely in the foreseeable future, it may be wasted energy trying to convince builders their users to adopt consistently less convenient workflows in the name of privacy, especially when their primary goal is broad adoption and financial sovereignty. Though it isn't wasted energy if their target users are privacy perusing individuals on such a transparent protocol. As a result, many of the external risks associated with transparent money, such as surveillance, targeted theft, extortion, kidnappings, or government overreach, cannot realistically be properly solved purely through operational discipline at population scale. The reality of the matter is, they'd be "solved" either by accepting custodial and institutional intermediaries, continue relying on traditional financial systems, pursue stronger protocol-level privacy if it ever arrives, or confront those risks more directly through improved personal security, legal protections, and broader political and social change. I don't like this reality, but it's what we have and what we'll deal with, unless some sort of major change or breakthrough happens at the base layer.

So one can't derive a Monero address from a nostr address because of different curves. I tried thinking what if there was a nostr that is ed25519, but still a no because monero has its own version of that. But then I thought "what if nostr was monero from the start?" but with domain seperation, having that as the reusable social layer, and then we derive a standard monero address from that? mnPub (public social) > 4/8 (private financial) nostr clients and relays would then need to support this "monero nostr" version along with the current "bitcoin nostr" version, with clean UX flows. didn't dig too deep into monero, so maybe this is a fail of an idea, but thought i'd throw it out there and perhaps it'll spark an idea in someone. #monero #nostr

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)

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