[BIP Proposal] Add sp() output descriptor format for BIP352

[Craig Raw]

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

[Oghenovo Usiwoma]

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

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPR5oBNCd65XaipOF%3DeXW7PT%2BJRVC4m6ey%2BX42aQsKa1YzA-Xw%40mail.gmail.com.

[Craig Raw]

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