Can you receive without handing out an address?

Evidence

Each numbered marker in the text points here, and the ↩ links lead back to every place that cites an entry. Quotes are verbatim from the BIP files at commit 3a10b5b, including their wiki markup; links open the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history, a test vector, or our own inference.

1. ↩ Author’s rationale The authors motivate the BIP by the privacy value of fresh addresses, which usually needs sender-receiver interaction (an address, a batch, or an xpub).

   BIP 352 L32

   Quoted source text (1)

   Using a new address for each Bitcoin transaction is a crucial aspect of maintaining privacy. This often requires a secure interaction between sender and receiver, so that the receiver can hand out a fresh address, a batch of fresh addresses, or a method for the sender to generate addresses on-demand, such as an xpub.

2. ↩ History BIP 352 (josibake, Ruben Somsen, Sebastian Falbesoner) is a Specification BIP assigned in 2023 and recorded as Complete; this snapshot is version 1.1.1.

   BIP 352 L4–10 BIP 352 L16

   Quoted source text (2)

   Title: Silent Payments Authors: josibake <josibake@protonmail.com> Ruben Somsen <rsomsen@gmail.com> Sebastian Falbesoner <sebastian.falbesoner@gmail.com> Status: Complete Type: Specification Assigned: 2023-03-09

   Version: 1.1.1

3. ↩ Rule BIP 352 specifies static payment addresses without on-chain linkability of payments or on-chain notifications.

   BIP 352 L24

   Quoted source text (1)

   This document specifies a protocol for static payment addresses in Bitcoin without on-chain linkability of payments or a need for on-chain notifications.

4. ↩ a b Rule An address is bech32m with HRP sp (mainnet) or tsp, the character q for version 0, and the 66-byte concatenation of B_scan and B_m; a v0 mainnet address is 116 characters.

   BIP 352 L205–209 BIP 352 L221

   Quoted source text (2)

   ** The human-readable part "sp" for mainnet, "tsp" for testnets (e.g. signet, testnet) ** The data-part values: *** The character "q", to represent a silent payment address of version 0 *** The 66-byte concatenation of the receiver's public keys, ''ser_P(B_scan) || ser_P(B_m)''

   For a silent payments v0 address, this results in a 116-character address when using the 2-character mainnet HRP ("sp")

5. ↩ a b Rule Version 0 addresses start sp1q; the version is carried as in bech32 addresses.

   BIP 352 L149

   Quoted source text (1)

   This document defines version 0 (''sp1q'').

6. ↩ a b Author’s rationale An address carries a scan key and a spend key so b_spend can stay in cold storage while scanning uses b_scan.

   BIP 352 L110

   Quoted source text (1)

   Bob can instead publish an address of the form ''(B_scan, B_spend)''. This allows Bob to keep ''b_spend'' in offline cold storage and perform the scanning with the public key ''B_spend'' and private key ''b_scan''.

7. ↩ a b Rule Receiver outputs are always BIP 341 taproot outputs.

   BIP 352 L185

   Quoted source text (1)

   * Receiver addresses are always [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot outputs

8. ↩ Test vector The first vector's address decodes to two 33-byte compressed keys, and the model re-encodes the same 116-character address.

   BIP 352 L209

   Quoted source text (1)

   The 66-byte concatenation of the receiver's public keys

9. ↩ Rule Simple case: Alice pays P = B + hash(a·B)·G; since a·B == b·A (ECDH), Bob finds P by computing hash(b·A) from the input public keys.

   BIP 352 L65–68 BIP 352 L68

   Quoted source text (2)

   * Let ''P = B + hash(a·B)·G'' * Encode ''P'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output Since ''a·B == b·A''

   Bob scans with his private key ''b'' by collecting the input public keys for each transaction with at least one unspent taproot output and performing the ECDH calculation until ''P'' is found

10. ↩ a b c Author’s rationale The stated goals include no increase in transaction size or cost, transactions that blend in, and no linking of transactions to a silent payment address by an outside observer.

    BIP 352 L44–46

    Quoted source text (1)

    * No increase in the size or cost of transactions * Resulting transactions blend in with other bitcoin transactions and can't be distinguished * Transactions can't be linked to a silent payment address by an outside observer

11. ↩ Rule The sender tweaks with the sum of the input private keys, a = a1 + … + an, and A = a·G.

    BIP 352 L101–104

    Quoted source text (1)

    Alice performs the tweak with the sum of her input private keys in the following manner: * Let ''a = a₁ + a₂ + ... + a_n'' * Let ''A = a·G''

12. ↩ Rule The input hash prevents a second payment from the same key from deriving the same outputs; it hashes the smallest outpoint and A.

    BIP 352 L90 BIP 352 L303

    Quoted source text (2)

    If Alice were to use a different UTXO from the same public key ''A'' for a subsequent payment to Bob, she would end up deriving the same destinations ''P_k''. To prevent this, Alice should include an input hash

    Let ''input_hash = hash_{BIP0352/Inputs}(outpoint_L || A)'', where ''outpoint_L'' is the smallest ''outpoint'' lexicographically used in the transaction

13. ↩ a b c Rule The sender computes ecdh_shared_secret = input_hash·a·B_scan, t_k as a tagged hash of the secret and k, and P = B_m + t_k·G; the receiver computes input_hash·b_scan·A and P_k = B_spend + t_k·G.

    BIP 352 L309–310 BIP 352 L312 BIP 352 L314 BIP 352 L343

    Quoted source text (4)

    ** Let ''ecdh_shared_secret = input_hash·a·B_scan'' ** Let ''k = 0''

    Let ''t_k = hash_{BIP0352/SharedSecret}(ser_P(ecdh_shared_secret) || ser₃₂(k))''

    Let ''P_mn = B_m + t_k·G''

    * Let ''ecdh_shared_secret = input_hash·b_scan·A''

14. ↩ a b c Rule Further outputs to the same receiver use k = 1, 2, …; after finding P_0 the receiver checks P_1 and stops at the first one not found.

    BIP 352 L80–84

    Quoted source text (1)

    Once he detects the first output, he must: * Check for ''P₁ = B + hash(b·A || 1)·G'' * If ''P₁'' is not found, stop

15. ↩ Rule The receiver spends with d = (b_spend + t_k + optional label tweak) mod n.

    BIP 352 L368–369

    Quoted source text (1)

    Let ''d = (b_spend + t_k + hash_{BIP0352/Label}(ser₂₅₆(b_scan) || ser₃₂(m))) mod n''

16. ↩ Test vector This site's silent payments model reproduces all 28 of BIP 352's send-and-receive vectors: sender outputs and shared secrets, receiver addresses, tweaks, shared secrets, found outputs and spending tweaks. The figures show six of them, recomputed at build time and checked against the published values.

    BIP 352 L383

    Quoted source text (1)

    A [[bip-0352/send_and_receive_test_vectors.json|collection of test vectors in JSON format]] is provided

17. ↩ a b Rule A label tweaks the spend key, B_m = B_spend + hash(b_scan || m)·G, so a receiver can tell payments apart without scanning for multiple addresses.

    BIP 352 L118–120 BIP 352 L356–357

    Quoted source text (2)

    Naively, Bob could publish multiple silent payment addresses, but this would require him to scan for each one, which becomes prohibitively expensive. Instead, Bob can label his spend public key ''B_spend'' with an integer ''m'' in the following way: * Let ''B_m = B_spend + hash(b_scan || m)·G''

    Compute ''label = output - P_k'' ***** Check if ''label'' exists in the list of labels used by the wallet

18. ↩ a b Rule Any UTXO with known output scripts can fund the transaction, but sender and receiver MUST derive the secret from P2TR, P2WPKH, P2SH-P2WPKH and P2PKH inputs only.

    BIP 352 L225–230

    Quoted source text (1)

    While any UTXO with known output scripts can be used to fund the transaction, the sender and receiver MUST use inputs from the following list when deriving the shared secret: * ''P2TR'' * ''P2WPKH'' * ''P2SH-P2WPKH'' * ''P2PKH''

19. ↩ a b Rule The receiver reads the key from the last witness item for P2WPKH and P2SH-P2WPKH, from the scriptSig for P2PKH, and from the scriptPubKey (output key) for P2TR, including script-path spends.

    BIP 352 L254 BIP 352 L265 BIP 352 L275 BIP 352 L283

    Quoted source text (4)

    Same as a keypath spend, the receiver obtains the public key from the ''scriptPubKey'' (i.e. the taproot output key)

    the receiver obtains the public key as the last witness item.

    the receiver obtains the public key as the last witness item.

    The receiver obtains the public key from the ''scriptSig''.

20. ↩ Rule In coin selection the sender excludes inputs with SegWit version > 1.

    BIP 352 L292

    Quoted source text (1)

    * Exclude inputs with SegWit version > 1

21. ↩ Author’s rationale Inputs with conditional branches or multiple keys are excluded because a malicious participant in a collaborative transaction could re-sign with different keys.

    BIP 352 L232

    Quoted source text (1)

    Inputs with conditional branches or multiple public keys (e.g. ''CHECKMULTISIG'') are excluded from shared secret derivation as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys.

22. ↩ a b Rule Only x-only and compressed public keys are permitted.

    BIP 352 L234

    Quoted source text (1)

    For all of the output types listed, only X-only and compressed public keys are permitted

23. ↩ a b Rule Script-path spends whose internal key is the NUMS point H are skipped.

    BIP 352 L256 BIP 352 L256

    Quoted source text (2)

    The one exception is script path spends that use NUMS point ''H'' as their internal key

    in which case the input will be skipped for the purposes of shared secret derivation

24. ↩ Rule For a taproot input, including a script-path spend, the sender MUST use the private key of the taproot output key; if it is not available the output cannot be an input, unless H is the internal key.

    BIP 352 L254 BIP 352 L293

    Quoted source text (2)

    Same as a keypath spend, the sender MUST use the private key corresponding to the taproot output key. If this key is not available, the output cannot be included as an input to the transaction.

    * For each taproot output spent the sending wallet MUST have access to the private key corresponding to the taproot output key, unless ''H'' is used as the internal public key

25. ↩ Rule The sender negates a taproot private key whose point has odd y, because the receiver assumes even y when summing x-only keys.

    BIP 352 L300 BIP 352 L300

    Quoted source text (2)

    check that the private key produces a point with an even Y coordinate and negate the private key if not

    since the receiver will assume the even Y coordinate when summing the taproot X-only public keys.

26. ↩ Rule The receiver MUST parse a P2PKH scriptSig for the key even when it does not match the template, to address third-party malleability.

    BIP 352 L283

    Quoted source text (1)

    The receiver MUST parse the ''scriptSig'' for the public key, even if the ''scriptSig'' does not match the template specified (e.g. <code><dummy> OP_DROP <Signature> <Public Key></code>). This is to address the [https://en.bitcoin.it/wiki/Transaction_malleability third-party malleability of ''P2PKH'' ''scriptSigs''].

27. ↩ Test vector Read by the model, the vectors with a malleated P2PKH scriptSig, uncompressed keys, a non-P2WPKH P2SH input and a NUMS script-path spend each have inputs that are skipped or parsed as the BIP requires, while the shared secret still matches.

    BIP 352 L442

    Quoted source text (1)

    Wallets should include inputs not in the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list when testing to ensure that only inputs from the list are being used for shared secret derivation.

28. ↩ Rule Coin selection MUST include at least one eligible input.

    BIP 352 L291

    Quoted source text (1)

    * At least one input MUST be from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list

29. ↩ Rule A v0 transaction MUST be scanned iff it has at least one taproot output, at least one eligible input, and spends no output with SegWit version > 1.

    BIP 352 L191–195 BIP 352 L194–195

    Quoted source text (2)

    For silent payments v0 a transaction MUST be scanned if and only if all of the following are true: * The transaction contains at least one BIP341 taproot output

    * The transaction has at least one input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list * The transaction does not spend an output with SegWit version > 1

30. ↩ a b Author’s rationale The benefits come at the cost of wallets scanning the blockchain; the authors call this generally feasible for full nodes but a challenge for light clients, and light-client support open research.

    BIP 352 L36

    Quoted source text (1)

    These benefits come at the cost of requiring wallets to scan the blockchain in order to detect payments. This added requirement is generally feasible for full nodes but poses a challenge for light clients. While it is possible today to implement a privacy-preserving light client at the cost of increased bandwidth, light client support is considered an area of open research

31. ↩ a b Rule The receiver computes P_k = B_spend + t_k·G starting at k = 0, checks the transaction's taproot output keys, rescans with k++ after each match, and stops when no match is found.

    BIP 352 L345–350 BIP 352 L350 BIP 352 L354 BIP 352 L362

    Quoted source text (4)

    ** Let ''outputs_to_check'' be the taproot output keys from all taproot outputs in the transaction (spent and unspent). ** Starting with ''k = 0'':

    *** Compute ''P_k = B_spend + t_k·G''

    Remove ''output'' from ''outputs_to_check'' and rescan ''outputs_to_check'' with ''k++''

    *** If no matches are found, stop

32. ↩ Rule Since version 1.1.0, a sender fails if a scan-key group exceeds K_max = 2323 addresses and a receiver stops at k = K_max, to mitigate quadratic scanning for adversarial transactions.

    BIP 352 L306 BIP 352 L347 BIP 352 L510–511

    Quoted source text (3)

    * If any of the groups exceed the limit of ''K_max'' (=2323) silent payment addresses, fail.

    *** If ''k == K_max'' (=2323), stop scanning.

    * '''1.1.0''' (2026-03-02): ** Introduce per-group recipient limit ''K_max'' to mitigate quadratic scanning behavior for adversarial transactions.

33. ↩ Author’s rationale Because the follow-up checks run only after a match, the authors call the added scanning cost negligible.

    BIP 352 L86

    Quoted source text (1)

    Since Bob will only perform these subsequent checks after a transaction with at least one output paying him is found, the increase to his overall scanning requirement is negligible.

34. ↩ Rule If no label matches, the receiver negates the output and checks again, because taproot outputs are x-only.

    BIP 352 L361 BIP 352 L361

    Quoted source text (2)

    If a label is not found, negate ''output'' and check a second time

    Unfortunately taproot outputs are X-only, meaning we don't know what the correct Y coordinate is.

35. ↩ Rule Label m = 0 is reserved for change; it is important that a wallet never hands it out.

    BIP 352 L132 BIP 352 L132

    Quoted source text (2)

    We reserve ''m = 0'' for this use case.

    It is important that the wallet never hands out the label with ''m = 0'' in order to ensure nobody else can create payments that are wrongly labeled as change.

36. ↩ Rule Every receiving silent payments wallet should at least scan for the change label when recovering from backup.

    BIP 352 L134

    Quoted source text (1)

    every receiving silent payments wallet should at least scan for the change label when recovering from backup in order to ensure maximum cross-compatibility.

37. ↩ Author’s rationale Light-client scanning is out of scope; an appendix sketches tweak data served per transaction and BIP 158 block filters.

    BIP 352 L461 BIP 352 L479

    Quoted source text (2)

    While this is out of scope for the current BIP

    Once a light client has the tweak data for a block, they can determine whether or not an output to them exists in the block using BIP158 block filters.

38. ↩ Author’s rationale An outside observer can easily tell that labeled addresses belong to one entity because they share B_scan; labels are not for separate identities.

    BIP 352 L128

    Quoted source text (1)

    It is important to note that an outside observer can easily deduce that each published ''(B_scan, B_m)'' pair is owned by the same entity as each published address will have ''B_scan'' in common. As such, labels are not meant as a way for Bob to manage separate identities

39. ↩ Author’s rationale The design keeps CoinJoins and MuSig/FROST inputs in mind, but recommends that all inputs belong to one entity because there is no formal proof of security in a collaborative setting.

    BIP 352 L38

    Quoted source text (1)

    The design keeps collaborative transactions such as CoinJoins and inputs with MuSig and FROST keys in mind, but it is recommended that the keys of all inputs of a transaction belong to the same entity as there is no formal proof that the protocol is secure in a collaborative setting.

40. ↩ Rule The sender should sign with DEFAULT, ALL, SINGLE or NONE; ANYONECANPAY is unsafe.

    BIP 352 L186

    Quoted source text (1)

    The sender should sign with one of the sighash flags ''DEFAULT'', ''ALL'', ''SINGLE'', ''NONE'' (''ANYONECANPAY'' is unsafe).

41. ↩ Rule All generated outputs MUST be in the final transaction; omitting P_i hides later outputs from the receiver.

    BIP 352 L320

    Quoted source text (1)

    All generated outputs MUST be present in the final transaction. If an output ''P_i'' with ''i < k'' is omitted, the receiver will not be able to find outputs ''P_j'' where ''i < j <= k''.

42. ↩ Rule Each output is derived independently, so regular backups are recommended and recovery requires scanning; a seed-only restore scans from the wallet birthday.

    BIP 352 L373 BIP 352 L375

    Quoted source text (2)

    Since each silent payment output address is derived independently, regular backups are recommended. When recovering from a backup, the wallet will need to scan since the last backup to detect new payments.

    can recover the full wallet history by scanning the blockchain starting from the wallet birthday.