Silent Payments — Technical

TECHNICAL_DOC // KEYS / SILENT-PAYMENTS

SILENT
PAYMENTS

Silent Payments (BIP 352) allow a sender to pay a recipient using a single static payment code — without the recipient ever publishing an address. Each payment derives a unique on-chain address via Diffie-Hellman over the sender's input keys, so no two payments to the same recipient look related on-chain. No interaction, no address reuse, no on-chain metadata.

THE_CORE_MECHANISM

KEY DERIVATION — SENDER SIDE

Recipient publishes static payment code: B_scan = b_scan × G (scanning public key) B_spend = b_spend × G (spending public key) Sender selects all input private keys: a1, a2, ... A_sum = a1×G + a2×G + ... (sum of input pubkeys) Sender computes shared secret: ecdh_shared = a_sum × B_scan t = hash(ecdh_shared || 0) (first output, k=0) Output public key sent to: P = B_spend + t×G On-chain: P appears as a normal P2TR address. No link to B_scan or B_spend visible to observers.

SCANNING — RECIPIENT SIDE

SCANNING FOR INCOMING PAYMENTS

Recipient sees transaction on-chain with output P. To check if P belongs to them: A_sum = sum of input pubkeys in the tx ecdh = b_scan × A_sum (same shared secret via ECDH) t = hash(ecdh || k) for k = 0, 1, 2, ... P_test = B_spend + t×G If P_test == P: this output is mine ✓ Spending key: b_spend + t (mod n) Scanning requires: b_scan key + full UTXO set (or tx data) Spending requires: b_spend key (can be in cold storage)

PRIVACY_PROPERTIES

WITHOUT SILENT PAYMENTS

Recipient reuses address or publishes new one per payment. Address reuse clusters UTXOs publicly. Fresh addresses require out-of-band coordination.

WITH SILENT PAYMENTS

Sender derives unique address from static code. Zero interaction needed. Every payment to same recipient looks like different person.

Multiple Outputs — Same Recipient

BIP 352

When sending multiple outputs to the same silent payment recipient in one transaction, each output increments the counter k to derive a distinct key.

First output: t0 = hash(ecdh || 0) → P0 = B_spend + t0×G Second output: t1 = hash(ecdh || 1) → P1 = B_spend + t1×G Third output: t2 = hash(ecdh || 2) → P2 = B_spend + t2×G All distinct P2TR outputs — recipient scans k=0,1,2,... until no match found.

Input Eligibility — Which Inputs Count

PROTOCOL RULE

BIP 352 specifies which transaction input types contribute to the ECDH sum. Only inputs with recoverable public keys are eligible.

Eligible inputs (contribute public key to A_sum): ✓ P2WPKH — compressed pubkey in witness ✓ P2TR — x-only pubkey from scriptPubKey ✓ P2PKH — compressed pubkey in scriptSig ✓ P2SH-P2WPKH — nested SegWit, pubkey in witness Not eligible: ✗ P2SH (arbitrary scripts — pubkey not recoverable) ✗ P2WSH (script hash — pubkey not directly recoverable) ✗ Coinbase inputs If no eligible inputs exist → silent payment cannot be made.

The TXID of the first eligible input is hashed into the shared secret to prevent reuse across transactions with identical key material.

Silent Payments vs BIP 47 Payment Codes

COMPARISON

BIP 47 (reusable payment codes) also enables static payment identifiers but requires a notification transaction on-chain before the first payment.

BIP 47 (PayNym): Requires: on-chain notification tx before first payment Cost: ~200-400 sat fee for notification Privacy: notification tx links payer and payee on-chain Adoption: Samourai Wallet (discontinued), Sparrow Wallet BIP 352 (Silent Payments): Requires: nothing — no on-chain setup Cost: standard tx fee only Privacy: no on-chain link between payer and recipient Scanning: receiver must scan every tx (computational cost) Adoption: Cake Wallet, Sparrow Wallet, Bitcoin Core (planned)

TERMINOLOGY_INDEX

Silent Payment

A payment to a static payment code that derives a unique address per transaction via ECDH, with no interaction.

Payment Code

A static identifier (B_scan || B_spend) published by the recipient once. Shareable like an email address.

ECDH

Elliptic Curve Diffie-Hellman. Allows two parties to derive a shared secret using each other's public keys.

Scan Key

b_scan — the private key used to identify incoming payments by scanning transactions. Can be kept online.

Spend Key

b_spend — the private key used to spend received outputs. Should be kept in cold storage.

BIP 352

The BIP specifying the Silent Payments protocol. Final status. Outputs are P2TR.

INTERACTIVE — TRY IT YOURSELF

PRIVACY / SILENT PAYMENTS

Silent Payments

Silent Payments (BIP352) allow a sender to pay a recipient's static address without any interaction — the recipient scans the blockchain to find payments. Each transaction generates a unique on-chain address derived from the sender's input keys and the recipient's scan+spend keys. No address reuse, no coordination, no pre-shared secrets.

KEY CONCEPTS

A silent payment address encodes two keys: a scan key B_scan and a spend key B_spend. The sender tweak uses their input private keys and the recipient's scan key. The recipient uses their scan private key to detect incoming payments.

SENDER SIDE — COMPUTE OUTPUT KEY

t = H(input_hash · Σ(a_i · A_i) · B_scan || k)
P_output = t·G + B_spend

RECIPIENT SIDE — SCAN FOR PAYMENTS

For each tx: t = H(input_hash · Σ(A_i) · b_scan || k)
Check if t·G + B_spend matches any output in tx
Spend key: p_output = t + b_spend (mod n)

input_hash = SHA256(smallest outpoint || Σ(A_i)) where outpoints are sorted lexicographically. This binds the tweak to specific UTXOs, preventing replay across transactions. k is an output index for sending multiple outputs to the same recipient.

SHARED SECRET DEMO

SENDER → RECIPIENT SHARED SECRETECDH key exchange

SENDER

INPUT PRIVATE KEY a (32 bytes hex)

RECIPIENT

SCAN PRIVATE KEY b_scan (32 bytes hex) SPEND PRIVATE KEY b_spend (32 bytes hex)

OUTPOINT (txid:vout hex string, for input_hash)

SILENT PAYMENT ADDRESS FORMAT

A silent payment address is a Bech32m-encoded string with HRP sp (mainnet) or sprt (testnet). It encodes both scan and spend public keys concatenated (66 bytes total for two compressed pubkeys).

ENCODE SILENT PAYMENT ADDRESS

SCAN PUBLIC KEY (33 bytes hex)

SPEND PUBLIC KEY (33 bytes hex)

PRIVACY COMPARISON

ADDRESS SCHEME	REUSE RISK	INTERACTION	ON-CHAIN LINKABILITY
P2PKH/P2WPKH (static)	HIGH	None (just publish addr)	All payments visible and linked
BIP47 PayNym	LOW	Requires notification TX	Notification TX reveals relationship
Silent Payments (BIP352)	NONE	None — scan blockchain	No on-chain linkage; outputs look like any Taproot
Stealth addresses (old)	NONE	None — scan blockchain	Requires OP_RETURN or ephemeral key marker

Scanning cost: Recipients must scan every transaction in every block to find payments. Light clients cannot do this efficiently without trusted servers. BIP352 includes a label mechanism where labels allow grouping payments (e.g., one label per contact) without additional scanning cost, since labels are deterministic tweaks on B_spend.