Published on: 2019-03-08T00:40:00+00:00
A recent discussion on the bitcoin-dev mailing list regarding Proprietary extension to Partially Signed Bitcoin Transactions (PSBT) has revealed different opinions. Andrew Chow expressed concern that such an extension would break the central idea of PSBT, which is to contain everything required to construct a transaction. He argued that relying on parties in the transaction to have state and remember details is not a reasonable assumption. However, other participants disagreed and suggested that it is acceptable for someone to use a proprietary extension to PSBT as long as it is used only between their own systems or with a translator to talk to ordinary PSBT elements.As a solution, they proposed adding a versioning field to indicate the specific PSBT dialect being used. This would allow for more reasonable error messages and help to identify any incompatible versions. The discussion highlighted the importance of maintaining the integrity and compatibility of PSBT, while also allowing space for innovation and customization for specific use cases.In an email thread on the bitcoin-dev mailing list, Andrew Poelstra, Director of Research at Blockstream, proposed several extensions to PSBT. The first proposal suggests adding a field to PSBT_GLOBAL_UNSIGNED_TX that contains only a transaction ID (txid) of the unsigned transaction. This would save bandwidth if signers have already seen the transaction or can construct it themselves. However, this proposal would break the central idea of PSBT.The second proposal is to add a version field to the global table, although its purpose remains unclear. The remaining proposals suggest adding various fields to per-input and per-output tables for different purposes. These include the confirmed depth of referenced txout, maps from SHA2 hashes to their 32-byte preimages, maps from public keys to 32-byte "tweaks" used in pay-to-contract construction, maps from public keys to partial nonce commitments, partial nonces, and partial signatures, and maps from signatures (or signature nonces) to sign-to-contract tweaks. However, these last two suggestions are considered premature and require further development and standardization of related protocols.Finally, Poelstra proposes adding a field (or family of fields) to every table that is "proprietary use" and guaranteed not to be defined by any future PSBT extension. Specifically, every field with key-type 0xFF could be considered "proprietary". The special field in the global table whose key is only 0xFF should be a "proprietary version field" with unspecified semantics, but an understanding that specific users might insert a GUID or something similar to recognize their own PSBTs.Overall, the discussion highlights the need for careful consideration when extending BIP174 and the importance of balancing innovation and customization with maintaining the integrity and compatibility of PSBT.
Updated on: 2023-08-02T00:35:30.194737+00:00