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

The email from Craig discusses various technical aspects and considerations related to Bitcoin development, specifically focusing on improvements and challenges associated with the implementation of Taproot and the management of silent payment addresses.

The initial part of the discussion emphasizes the significance of scanning from the Taproot activation height due to the computational requirements needed to match outputs for all eligible public keys as the blockchain grows. This approach contrasts with standard descriptors, as it requires referencing the blockchain to describe outputs, imposing a significant computational burden not encountered with other descriptors. Therefore, it is suggested to include an optional argument to mitigate these challenges temporarily.

Craig also delves into the limitations imposed by the maximum number of labels that can be scanned during the recovery process. The discussion highlights how each additional label scanned adds significantly to the computational workload, evidenced by benchmark numbers that show scanning for 100,000 labels as being cost-prohibitive. He suggests that in most cases, creating a new BIP44 account may be a more efficient solution for managing additional silent payment addresses than relying on labels, which have a limited use case.

Furthermore, the email outlines the benefits of using specific key formats and expressions, like "sp(scankey,spendkey)", for silent payments. This method offers several advantages: it provides a self-describing format that clarifies the use and sensitivity of the key material, leverages Bech32m encoding for strong error detection and clear differentiation of characters, prevents the accidental mixing of unrelated scan and spend keys, and introduces versioning for silent payments. Additionally, this format bears similarity to xpubs, commonly used in many wallets, simplifying the user experience both for developers and end-users.

Overall, the message underscores the need for careful consideration of the computational demands and user experience in the development of Bitcoin features, particularly those related to Taproot and silent payment addresses.