@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

Letters of Silence Dogood

Silence Dogood - Wikipedia

Also, thanks to whoever you are!

Thanks everyone for the great discussion and awesome feedback. I have updated the Nostr Silent Payments gist with important security caveats. Keep in mind, the use case I am aiming for is not social media, but, rather, digital trade where there might be millions maybe billions of npubs from agents and devices that need to trade and make payments - and be verifiably attributed npub->payment address. FWIW, this is what I was aiming for with a Cashu/Lightning stack. But this is far more simpler and does not require any operating payment infrastructure (nodes, mints, etc). It does require a trusted scanning infrastructure, but that is a tradeoff that I am willing to explore.

Gist

Nostr Silent Payments

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

The question boils down to this: who do you trust more? 1. A #cashu mint that has your funds, or 2. A #frigate server that has your keys. Both options are actually valid, and even better for each option you can decide which servers to trust.