#bikestr

“The deeper I look at [nostr], the more it feels less like a social protocol and more like a carefully disciplined refusal to solve problems that protocols cannot actually solve.” I care more about the protocol itself than I care about the recent social media drama and the cypherpunk virtue signalling.

Simplicity Is Completeness

What Nostr quietly revealed

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.

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.

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

Nostr Silent Payments Every npub has a verifiable Silent Payments address that anyone can generate and send payments to. Peer-to-Peer Payment. End-to-End Privacy. I did the math. I have working code. It works. This is the future of private payments.

‘Architecture creates possibilities.’ h/t to @𒐌 for the reframing

View quoted note →