NIP-SP: Silent Payment Addresses in Profile Metadata

draft optional

Abstract

This NIP defines how a Nostr user advertises a Bitcoin BIP-352 silent payment address, so that anyone can pay them on-chain without interaction, address reuse, or an identity-linked receiving history.

Motivation

Deriving a Bitcoin address deterministically from an npub produces a static, public, identity-linked address. This is close to the worst-case Bitcoin privacy pattern: address reuse, identity linkage, and full UTXO graph exposure. It also enables targeted dust attacks against a public, enumerable list of identities.

BIP-352 silent payments solve this at the Bitcoin layer. The receiver publishes one static address, and each sender derives a unique on-chain output via ECDH using their own transaction inputs. No two payments share an address, and no observer can link payments to a common recipient.

The unsolved piece is distribution. A silent payment address is long (roughly 117 characters) and impractical to share by hand. Nostr provides a signed, replicated, identity-keyed publication layer that solves discovery without DNS, an LNURL server, or any custodian.

Nostr’s role is discovery and verification only. The silent payment address is generated independently by the user’s Bitcoin wallet. Its keys MUST NOT be derived from the Nostr identity key.

Specification

A client MAY include a silent payment address in the kind:0 content object under the key sp_address:

{
  "name": "alice",
  "about": "...",
  "sp_address": "sp1q..."
}

The value MUST be a valid BIP-352 silent payment address in bech32m form. Clients that do not understand the field MUST ignore it.

A user has at most one sp_address. To update it, the user republishes kind:0 with a new value, the same way any other profile field is updated. The latest signed kind:0 event is authoritative.

Network

A BIP-352 address encodes its network in its human-readable prefix (sp for mainnet, tsp for testnet/signet). A wallet MUST confirm the resolved address matches its own network and MUST abort on a mismatch.

Sending

To pay a user, a sending wallet:

1. Fetches the recipient’s kind:0 event and reads the sp_address field.
2. Verifies the event’s signature corresponds to the recipient’s npub.
3. Validates the address: well-formed BIP-352 bech32m, correct network. If any check fails, the wallet MUST abort and MUST NOT fall back to any other address — in particular, MUST NOT derive an address from the recipient’s npub.
4. Derives the on-chain output locally per BIP-352 and broadcasts a standard Bitcoin transaction.
5. The wallet MUST NOT publish any public Nostr event asserting that the payment occurred. The payment is silent by design; a signed event naming sender, recipient, and payment is a zap (NIP-57) — a public, deanonymizing record — and negates the privacy BIP-352 and this NIP exist to provide. Any payment confirmation MUST be delivered privately (see Payment notification).

The payment is an ordinary BIP-352 transaction. Nostr is not involved in settlement and learns nothing about it.

Payment notification (optional)

After payment, a sender MAY notify the recipient with a NIP-17 private direct message identifying the transaction (txid, output index, amount, optional memo). This keeps payment metadata off public relays.

Relationship to Other NIPs

This NIP provides address resolution only. It is intended to compose with NIPs that reference an on-chain payment rail but do not themselves locate an address — for example, a NIP that lists a silent_payment payment method can use the resolution defined here to obtain the counterparty’s address. Composition is by convention: a NIP naming silent_payment need not depend on this NIP, and this NIP defines no pricing, invoicing, or transaction semantics of its own.

Out of Scope

The following are deliberately excluded to keep this NIP minimal:

• Amount, invoicing, and payment requests. This NIP publishes an address; it does not request a specific payment.
• Multiple labeled addresses, rotation, expiry. A user has one silent payment address, updated by republishing kind:0. Users requiring labeled addresses for separate purposes (e.g. donations vs. business) can manage that out-of-band; the spec does not attempt to standardize it.
• Multisig recipients. BIP-352 currently defines single-key recipients only.
• Public payment receipts or zap-style events. A public event asserting an on-chain payment between identities is a zap; wrapping a silent payment in one negates its privacy. Excluded by design; see Sending, Step 5.
• Spending-side privacy. This NIP concerns receiving only.

Security and Privacy Considerations

• Key independence. The silent payment address MUST be generated independently by the user’s Bitcoin wallet. Deriving its keys from the Nostr secret key would couple identity compromise to fund compromise and is forbidden.
• Key custody and signing. The SP private key is a Bitcoin spending key. It MUST be generated and custodied by the user’s Bitcoin wallet, and MUST NOT be held by the Nostr client or by a NIP-46 remote signer. The Nostr layer handles only the public SP address: a client obtains the address from the wallet, writes it to kind:0, and signs that profile event with the identity key — locally or via a NIP-46 remote signer, exactly as any other profile update. Generating the SP keypair requires no access to the Nostr secret key; signing the publication event MUST NOT be conflated with custody of the SP key.
• Receiving only. BIP-352 protects the receiving side. Spending silent payment outputs remains subject to normal Bitcoin privacy considerations, including the common-input-ownership heuristic.
• Untrusted input. Relays do not validate event content. A sending wallet MUST treat a resolved address as untrusted input and fully validate it (Sending, Step 3) even when the event signature is valid.
• Updates are eventually-consistent. kind:0 is a replaceable event; a republished profile replaces the prior version on each relay it reaches, but sender clients may cache profiles and use a stale sp_address until they refetch. Senders SHOULD re-resolve the address shortly before payment. Users who require an address that can be immediately and verifiably retired (e.g. after key compromise) are not well served by this spec; the appropriate response in that case is to rotate the underlying SP keypair, republish kind:0, and accept the propagation window.
• Resolution metadata. Querying a relay for a user’s profile is itself observable: a relay operator can see which identity requested whose profile, leaking payment intent. Senders concerned with this SHOULD resolve across multiple relays or from cached profile data rather than issuing a targeted query.

Rationale

Nostr is the discovery and verification layer; Bitcoin is the payment layer. The identity key announces one address; it never generates one, and it never proliferates into per-label addresses. This preserves the zero-setup experience of paying any npub while eliminating the privacy harms of identity-derived addresses, and it keeps the spec small enough to implement correctly in a single profile field.

Reference Implementation

An early implementation exists as a fork of the Ditto client. It publishes the sp_address profile field; readers SHOULD treat it as a work in progress, not a normative reference.