From: Craig Raw <craigraw@gmail.com>
To: Oghenovo Usiwoma <eunovo9@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Add sp() output descriptor format for BIP352
Date: Thu, 4 Dec 2025 13:02:33 +0200 [thread overview]
Message-ID: <CAPR5oBPH=mbv4N3_4vuCcf+mDTCiT52WDb=qQ6KNuT=6Qr5tKA@mail.gmail.com> (raw)
In-Reply-To: <CAOCjZ9STHWBvO1J6vYsU1YE_91NhoEAeqGYR3d9yNKqWwvTwww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7380 bytes --]
Hi Novo,
Responses inline:
> I'm not sure adding a block height does much to reduce scanning burden.
We can already scan from the taproot activation height and it won't matter
much anyway, because the chain will get longer and this only helps
temporarily.
I'm not sure I follow here. Since we need to retrieve and compute possible
matching outputs for all eligible public keys in the chain, having a block
height later than the Taproot activation date can make a significant
difference, and will make a greater difference in future as the chain grows.
> Is there any reason to add the birthday to the descriptor? Other
descriptors do not do this.
The difference between this and other descriptors is that it cannot
describe outputs without reference to the blockchain. This, combined with
the significant computational burden which other descriptors do not have to
bear, is reason enough I think to include it here as an optional argument.
> For example, we can set the maximum number of labels in the bip; wallets
will only have to scan for this max number of labels during recovery and if
a wallet goes beyond this maximum number, they have gone beyond the bip and
are now responsible for ensuring full recovery of funds.
The problem with this approach is that scanning for each additional label
adds incrementally and non-trivially to the computational burden. For each
label, there is an EC point addition and comparison against all taproot
outputs for an eligible transaction. Some benchmark numbers indicating the
relative cost of each additional label are in [1], demonstrating that
scanning for 100k labels is cost-prohibitive. As an aside, I will add that
labels have a limited use case, and in most cases a new BIP44 account is a
better choice for additional silent payment addresses based on the same
seed.
> Given the above points, I argue that we don't need to introduce new scan
and spend key formats, and we can use "sp(scankey,spendkey)".
While not strictly necessary, using spscan and spspend key expressions make
for a much better user experience and reduce the chance for user error.
With this encoding we get:
1. A self-describing format which makes the use and sensitivity of the
key material immediately obvious
2. The advantages of Bech32m encoding, including strong error detection
and unambiguous characters
3. Safety from accidentally mixing different unrelated scan and spend
keys
4. Versioning to indicate silent payments version 0
5. A similar format to an xpub, the display of which is a common user
interface element in many wallets which makes things simpler for wallet
developers and users alike
--Craig
[1]: https://delvingbitcoin.org/t/bip352-private-key-formats/2080/11
On Thu, Dec 4, 2025 at 11:39 AM Oghenovo Usiwoma <eunovo9@gmail.com> wrote:
> Hi Craig, thank you for taking this up. I have the following comments,
> based on a light inspection of your original email.
>
> > In order to reduce the scanning burden, a block height may be optionally
> specified in the sp() expression as a second argument for a wallet birthday.
>
> I'm not sure adding a block height does much to reduce scanning burden. We
> can already scan from the taproot activation height and it won't matter
> much anyway, because the chain will get longer and this only helps
> temporarily.
>
> Users can also specify a "wallet birthday" in their wallets which can be
> used for scanning. Is there any reason to add the birthday to the
> descriptor? Other descriptors do not do this.
>
> > Finally, zero or more positive integers may be specified as further
> arguments to scan for additional BIP352 labels. The change label (m = 0) is
> implicitly included.
>
> In
> https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#backup-and-recovery
> , a strategy to recover funds from labels is specified. We can attempt to
> make this stronger and avoid the need to also include an integer for
> labels. For example, we can set the maximum number of labels in the bip;
> wallets will only have to scan for this max number of labels during
> recovery and if a wallet goes beyond this maximum number, they have gone
> beyond the bip and are now responsible for ensuring full recovery of funds.
>
> > In summary a new top level script expression sp() is defined, which
> takes as it's first argument one of two new key expressions:
> - spscan1q... which encodes the scan private key and the spend public key
> - spspend1q... which encodes the scan private key and the spend private key
>
> Given the above points, I argue that we don't need to introduce new scan
> and spend key formats, and we can use "sp(scankey,spendkey)".
>
> I'm happy to hear any counter arguments you have.
>
> Novo
>
> On Thu, 4 Dec 2025, 12:40 pm Craig Raw, <craigraw@gmail.com> wrote:
>
>> Hi all,
>>
>> There is a practical need for a silent payments output descriptor format
>> in order to enable wallet interoperability and backup/recovery. There has
>> been some prior discussion on this topic [1][2] which this BIP proposal
>> builds on:
>>
>> https://github.com/bitcoin/bips/pull/2047
>>
>> In summary a new top level script expression sp() is defined, which takes
>> as it's first argument one of two new key expressions:
>>
>> - spscan1q... which encodes the scan private key and the spend public
>> key
>> - spspend1q... which encodes the scan private key and the spend
>> private key
>>
>> The outputs may then be generated by combining this key material with the
>> sender input public keys.
>>
>> In order to reduce the scanning burden, a block height may be optionally
>> specified in the sp() expression as a second argument for a wallet
>> birthday. Finally, zero or more positive integers may be specified as
>> further arguments to scan for additional BIP352 labels. The change label (m
>> = 0) is implicitly included.
>>
>> Examples:
>> sp(spscan1q...)
>> sp([deadbeef/352'/0'/0']spscan1q...,900000)
>> sp(spspend1q...,842579,1,2,3)
>> sp([deadbeef/352'/0'/0']spscan1q...,900000,1,5,10)
>>
>> --Craig
>>
>> [1]:
>> https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-payment-descriptors
>> [2]: https://delvingbitcoin.org/t/bip352-private-key-formats/2080
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPR5oBPH%3Dmbv4N3_4vuCcf%2BmDTCiT52WDb%3DqQ6KNuT%3D6Qr5tKA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9920 bytes --]
prev parent reply other threads:[~2025-12-04 11:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-04 6:45 Craig Raw
2025-12-04 9:38 ` Oghenovo Usiwoma
2025-12-04 11:02 ` Craig Raw [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPR5oBPH=mbv4N3_4vuCcf+mDTCiT52WDb=qQ6KNuT=6Qr5tKA@mail.gmail.com' \
--to=craigraw@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=eunovo9@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox