This is an attempt to communicate the value of the nostr protocol outside of the bubble.

Simplicity Is Completeness

What Nostr quietly revealed

#bikestr

Updated Nostr Silent Payments gist at the link below. The gist now includes two example scripts to validate a silent payment transaction and sweep a silent payment transaction. The example scripts have been implemented using the Python standard libraries only (no additional installs such as secp256k1, bech32, etc.) so you can see how everything works from the ground up - even how the public key points are created, added, etc. Also, the threat model has been updated. Though it can be used by your primary social media npub, that is not recommended. There are many different use cases (not related to social media) where an npub with a corresponding NIP-05 address may be required to privately receive funds.

Gist

Nostr Silent Payments

Nostr Silent Payments. GitHub Gist: instantly share code, notes, and snippets.

Onboarding onto nostr be like:

@martipos hello!

The Nostr Silent Payments gist note is now updated with a Receiver Culpability and Donor Entrapment section. As I document this, it's become clear to me that while #BIP352 is an awesome privacy advancement, the threat model is clearly not yet worked out. Read all about it here:

Gist

Nostr Silent Payments

Nostr Silent Payments. GitHub Gist: instantly share code, notes, and snippets.

1. Generate a Silent Payment Address 2. Solicit Funds from Donors 3. Spend the Funds 4. Dox the Scan Key 5. Dox all your Donors 6. Deny it was your Silent Payment Address 7. Repeat #BIP352

Hey @YakiHonne - can you fix your notifications so that notifications from muted users don't appear? I am getting notifications from #satsandsports whom I no longer follow and have muted. The other clients seem fine. Thanks.

Securely sharing a private key to a public server that you trust? No way! #BIP352

Gist

Nostr Silent Payments

Nostr Silent Payments. GitHub Gist: instantly share code, notes, and snippets.

There’s no such thing as a trustless transaction. You need to at least trust your counterparty that they won’t disclose a private key that could doxx you.

Updated gist at starting at the section in the link below. There is also another section following discussin the use of public scanning servers. PLS, if you value safety and privacy, you at least owe it to the senders/donors of your users, read this. #BIP352

Gist

Nostr Silent Payments

Nostr Silent Payments. GitHub Gist: instantly share code, notes, and snippets.

Hear me out. It wasn't my idea to expose a private key for Nostr Silent Payments. It wasn't even in the original proposal until I began to explore using the Sparrow Frigate server and what is proposed in BIP352. I've concluded that sharing any form of a private key (hardenened derived or otherwise) is a BAD IDEA! Telling a user to share a private key, even though it is hardened is IRRESPONSIBLE. So please redirect your private-key-sharing rage to the authors of BIP352 who introduced the concept in the first place. I am also coming to the conclusion that BIP352, though it has some great ideas, is a DANGEROUS PROPOSAL on its own because it encourages a user to expose a private key, if doxxed, exposes all of the donors to the silent payment address. Though the spend key is still safe and the funds are safe for the recipient, it introduces a risk for any sender/donor to that address. The receiver can issue a new silent payments address, but the DONORS REMAIN EXPOSED. If you care about your own privacy and security, and don't really care about the security and privacy of the donors who send to you, then BIP352 os great! But otherwise, I considering BIP352, on its own, a DANGEROUS PROPOSAL. Read all about it below: Direct excerpt from BIP352 "Spend and Scan Key Since Bob needs his private key b to check for incoming payments, this requires b to be exposed to an online device."

BIP 0352 - Bitcoin Wiki