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
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:
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
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.