[BIP Proposal] Add PSBT_IN_SP_TWEAK field

The initiative seeks to address a gap in the existing PSBT specifications by proposing modifications that would accommodate the nuances of silent payment transactions. Silent payments, as delineated in BIP 352, introduce a novel method for creating and spending Pay-to-Taproot (P2TR) outputs, necessitating adjustments to the PSBT format to fully support this protocol.

The proposal outlines the introduction of additional fields within the BIP 370 PSBTv2 standard, specifically designed to include silent payment tweaks. These tweaks are essential for the spending of silent payment outputs and might also find utility in other protocols leveraging taproot tweaks not strictly adhering to the BIP 340 specification. This development stems from the recognition that the current PSBT fields do not cater to the requirements of silent payments, primarily due to the distinct approach employed in generating outputs under this scheme.

Further examination reveals that BIP 375, alongside BIP 374, provides guidance on creating outputs locked with silent payment keys through PSBTs but stops short of detailing the unlocking mechanism for these outputs in transaction scenarios. This omission signals the need for new field definitions enabling PSBTs to encapsulate the requisite information for tweaking taproot keys divergent from the BIP 340 tagging scheme. The proposed solution introduces per-input types aimed at facilitating this functionality, notably a field designated for raw taproot key tweaks without relying on pre-existing fields unsuitable due to their inherent characteristics or the specific nature of the content they accommodate.

The rationale behind these additions underscores the limitations of current PSBT fields in addressing the demands of silent payment output spending, highlighting the inadequacy of fields like PSBT_IN_BIP32_DERIVATION and PSBT_IN_TAP_MERKLE_ROOT in this context. The proposition for a PSBT_IN_TAP_RAW_TWEAK field emerges as a more versatile and generalized approach, albeit with considerations around its interpretation by hardware wallets and the potential brittleness of proprietary field usage across different implementations.

This proposal, while introducing new elements to the PSBT landscape, maintains backward compatibility by virtue of PSBT's extensible design, ensuring that older software versions simply overlook unrecognized fields. The document detailing this proposal, along with test vectors and related works, is available for review and feedback at this link, inviting contributions from the wider community to refine and enhance the proposed standards for integrating silent payments into the PSBT framework.