NIP-352: Bitcoin Silent Payment Address

[i2dor]

Proposes kind:30352 as the receiver-controlled announced address layer for Bitcoin Silent Payments on Nostr.

Relationship to NSP (#2355)

Complements NSP, does not compete with it:

• NSP — deterministic derivation from npub, zero receiver action, no rotation possible, no signed publication
• NIP-352 — receiver signs and publishes their sp1... address as a kind:30352 event; derivation method not mandated

When a kind:30352 event exists, senders SHOULD prefer it over NSP derivation — it represents the receiver's explicit and current choice. When none exists, NSP is the natural fallback.

Key design decisions

• kind:30352 (addressable, 30000–39999) so mainnet and signet have independent slots via d-tag. kind:10352 would be wrong: the d-tag is not part of the relay's deduplication key in the replaceable range, so a signet publication would overwrite mainnet.
• Derivation out of scope — the sender needs only the sp1... string. Whether the receiver derived it from their Nostr key, a hardware wallet, or an independent keypair is irrelevant to the protocol.
• payment_pubkey optional — a provenance hint for clients that want to verify the address was legitimately derived; senders do not need it to pay.
• Publication tradeoff — publishing kind:30352 is an affirmative act. The receiver gains control (rotation, sub-key, opt-out from NSP derivation) but gives up NSP's non-attribution property. With NSP, no event is ever signed or published, so the receiver can truthfully say they never established intent to receive Bitcoin payments. A kind:30352 event is a signed statement of that intent. The choice between the two is a trust-model and legal-posture decision, not a technical one.

Running implementation

Nostru — Chrome extension that publishes and discovers kind:30352 events.