From: Oghenovo Usiwoma <eunovo9@gmail.com>
To: Craig Raw <craigraw@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:38:48 +0400 [thread overview]
Message-ID: <CAOCjZ9STHWBvO1J6vYsU1YE_91NhoEAeqGYR3d9yNKqWwvTwww@mail.gmail.com> (raw)
In-Reply-To: <CAPR5oBNCd65XaipOF=eXW7PT+JRVC4m6ey+X42aQsKa1YzA-Xw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4361 bytes --]
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/CAOCjZ9STHWBvO1J6vYsU1YE_91NhoEAeqGYR3d9yNKqWwvTwww%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6256 bytes --]
next prev parent reply other threads:[~2025-12-04 10:12 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 [this message]
2025-12-04 11:02 ` Craig Raw
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=CAOCjZ9STHWBvO1J6vYsU1YE_91NhoEAeqGYR3d9yNKqWwvTwww@mail.gmail.com \
--to=eunovo9@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=craigraw@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