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

This proposal outlines the creation of a top-level script expression named sp(), designed to facilitate silent payments by combining key material with sender input public keys. Specifically, it introduces two new key expressions: spscan1q.., which combines the scan private key with the spend public key, and spspend1q.., which pairs the scan private key with the spend private key. This mechanism aims to streamline the generation of outputs through these encoded keys.

An optional feature within the sp() expression allows for specifying a block height as a "wallet birthday". This option is intended to mitigate the scanning burden by narrowing the search window for transactions relevant to the wallet. Additionally, the proposal permits the inclusion of zero or more positive integers as arguments to identify additional BIP352 labels, with the change label (m = 0) implicitly included. Examples provided illustrate how these components can be combined within the sp() expression to cater to various use cases.

Critique on this proposal centers on several aspects, including the practicality and necessity of integrating a block height for reducing scanning burdens, given the evolving length of the blockchain and existing mechanisms for designating a "wallet birthday" in wallets. Questions are raised about the proposed addition of specific block heights to descriptors, a feature not common in other descriptors due to its temporary relief from scanning challenges and the distinctive computational demands of this proposal compared to others.

Further debate addresses the proposal's approach to managing BIP352 labels. The suggestion to cap the number of labels in the BIP to ease recovery processes is critiqued for potentially increasing the computational load significantly with each additional label scanned. The dialogue underscores the efficiency concerns associated with scanning for an extensive number of labels, highlighting the inefficiency of scanning for 100k labels.

Lastly, the rationale behind introducing new scan and spend key formats (spscan and spspend) is defended. Arguments in favor emphasize the user experience benefits, including a self-describing format, error detection strengths of Bech32m encoding, prevention of mix-ups between different key types, and versioning for silent payments. These formats aim to simplify the integration and usage in wallets by aligning with familiar user interface elements like xpub displays, thereby enhancing both developer and user experiences with silent payment addresses.