delvingbitcoin

BIP352: PSBT support

BIP352: PSBT support

Original Postby andrewtoth

Posted on: May 20, 2024 17:56 UTC

The email discusses technical enhancements and considerations regarding the implementation of silent payments within the Partially Signed Bitcoin Transactions (PSBT) framework.

The sender proposes not to include a placeholder scriptpubkey for fee calculation purposes in unsigned transactions to prevent older versions from mistakenly signing it, suggesting instead that PSBT_OUT_SCRIPT be made optional when outputs are added by the constructor. This approach is aimed at avoiding the inclusion of silent payment fields by older implementations that do not recognize them.

Further, the email outlines measures to ensure the integrity and finality of transaction outputs and silent payment addresses. By setting the Inputs Modifiable Flag and the Silent Payments Modifiable Flag to false, the system prevents any changes to inputs and the addition of new silent payment outputs after they are generated. This ensures that outputs need only be generated once and simplifies fee calculations by allowing the use of taproot output size for silent payment outputs.

Additionally, the sender raises concerns about ensuring that outputs being spent comply with certain criteria, such as not being a segwit witness version greater than 1. To address this, the email suggests merging the roles of Constructor and Updater within the PSBT framework to facilitate discrimination between eligible and non-eligible prevouts. This merge aims to maintain mutual exclusion between silent payment outputs and inputs designated as ANYONECANSPEND or Segwit version greater than 1. The email details how flags like Silent Payments Modifiable and Has Silent Payments can help enforce these rules, though it acknowledges challenges in dealing with Segwit version > 1 inputs due to the timing of input addition and scriptPubkey specification.

The discussion highlights the technical complexities involved in implementing silent payments in PSBTs, emphasizing the need for careful design to ensure compatibility, security, and adherence to intended transaction parameters.