BIP352: Add extra encoding formats for scanning and spending #2026

1. 
   junderw commented at 5:25 am on November 1, 2025: contributor

   Based on a discussion I started on Delving Bitcoin

   Also related: BTC Transcripts

   BIP authors: @josibake @RubenSomsen

   ---

   These two new encodings are a way for Silent Payment users to:

   1. Delegate scanning and wallet UTXO management to self hosted services like BTCPayServer
   2. Encode secret information including birthday and labels used, so that silent payment wallets can be exported and imported across wallets without information loss.

   I was debating whether to make the non-address encodings into descriptors instead. But that would be an easy change to make.

   Just creating this PR so that specific discussions about wording can take place.

   Thanks.

2. BIP352: Add extra encodings 51e1a91af1
3. jonatack added the label Proposed BIP modification on Nov 1, 2025
4. jonatack added the label Pending acceptance on Nov 1, 2025
5. 
   jonatack commented at 10:32 pm on November 1, 2025: member

   cc BIP authors @josibake and @RubenSomsen for feedback
6. BIP352: Make max_label to encode used labels ae9cd401df
7. in bip-0352.mediawiki:255 in 51e1a91af1

   250+
   251+* Let ''b<sub>scan</sub> = Receiver's scan private key''
   252+* Let ''b<sub>spend</sub> = Receiver's spend private key''
   253+* Let ''birthday = The block height at wallet creation''
   254+** If ''birthday'' is unknown or if recovering from a BIP39 seed, use block height 842579 (May 8, 2024)<ref name="why_birthday_842579"></ref>
   255+* Let ''labels = [m<sub>1</sub>, m<sub>2</sub>, ..., m<sub>n</sub>]'' an optional array of label integers
   

   ---

   ---

   

   nymius commented at 3:36 pm on November 3, 2025:

   I prefer a single number to show the stop limit instead of a list of labels, to push users towards a “dense” range of labels and produce a shorter, fixed size encoding, i.e., spspend<scan><spend><birthday>15 for a wallet with at most 15 revealed labels. The change label is always assumed. The possible value will range between [1, 2**32 - 1].

   ---

   

   jvgelder commented at 4:32 pm on November 3, 2025:

   I think this is also the intention of the BIP authors as they mention Let Bm = Bspend + hash(bscan || m)·G where m is an incrementable integer starting from 1

   ---

   

   junderw commented at 10:17 am on November 4, 2025:

   Good idea. Done.
8. in bip-0352.mediawiki:280 in ae9cd401df

   278 
   279-When scanning for payments, wallets MUST always check for label ''m = 0'' (the change label), even if it is not explicitly included in the list of appended labels. This ensures compatibility across different wallet implementations and prevents loss of funds if the wallet has generated change outputs using the reserved change label.
   280+When scanning for payments, wallets MUST always check for label ''m = 0'' (the change label), regardless of the ''max_label'' value. This ensures compatibility across different wallet implementations and prevents loss of funds if the wallet has generated change outputs using the reserved change label.
   281 
   282-Wallet implementations SHOULD include all labels that have been distributed or used when exporting the wallet key material. However, wallets recovering from an ''spscan'' or ''spspend'' encoding SHOULD be prepared to scan for additional labels beyond those included in the encoding, as users may have shared additional labeled addresses.
   283+When a ''max_label'' value is present in the encoding, wallets MUST scan for all labels in the range [0, ''max_label''], inclusive. This design encourages users to use a dense range of labels (e.g., 1, 2, 3, 4, 5) rather than sparse labels (e.g., 1, 100, 1000), resulting in more efficient scanning and a fixed-size encoding.
   

   ---

   ---

   

   nymius commented at 1:11 pm on November 4, 2025:

   I wouldn’t say the scanning is more efficient with a dense range, what is more efficient is the backup of the label information. For scanning on fully fledged scanners, the use of any number of labels is as performant as the use of no labels. For light clients the cost of checking N labels is equal to N times the use of no labels. Additionally, the bandwidth consumption is also equal to N times the use of no labels.

   ---

   

   nymius commented at 1:13 pm on November 4, 2025:

   To clarify my original point, the reason I would do it like this is to produce a shorter, fixed size encoding and have a compact backup format.

   ---

   

   setavenger commented at 6:54 pm on November 10, 2025:

   I wouldn’t say the scanning is more efficient with a dense range, what is more efficient is the backup of the label information.

   I agree with that. The number of labels is relevant not their m number.

Contributors
junderw jonatack nymius jvgelder setavenger

Labels
Proposed BIP modification Pending acceptance