bitcoin
PSBT: Add pay-to-contract tweaks to tx inputs
A number of protocols utilizes pay-to-contract and/or sign-to-contract public key tweaks. Inclusion of the tweak information into outputs (for pay-to-contract) or inputs (for sign-to-contract) as a security measure requires presence of full information from which the tweak is generated, i.e. protocol-specific and SHOULD not be a part of this standard. However, to spend already existing output containing pay-to-contract commitment a signer must apply raw tweak value to the private key. This operation is safe even if the meaning of the tweak is unknown since it does not provides any commitment to any external data. Since this operation is not protocol-specific I propose to add standard fields in order to provide signers with necessary information.
Looking for Concept ACK and I will add to the PR changes to other PSBT-related BIPS and more information on the tweaks.
CC @achow101
See also https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016713.html where I proposed something like this and achow gave me a concept ACK, but I then did not follow up on this (except for the Miniscript-related fields).
In accordance with https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#procedure-for-new-fields, these fields should first be proposed on the bitcoin-dev mailing list
I will write a proposal to bitcoin-dev taking @apoelstra as a starting point over the holidays - and after discussion there will update this PR
BIP 174 is Final... should be a new BIP (or maybe part of PSBTv2 if it's not done?)
@luke-jr BIP-174 allows adding new fields in a backward-compatible manner:
The Partially Signed Transaction format can be extended in the future by adding new types for key-value pairs. Backwards compatibilty will still be maintained as those new types will be ignored and passed-through by signers which do not know about them.
The procedure for adding new fields is the following:
New fields should first be proposed on the bitcoin-dev mailing list. If a field requires significant description as to its usage, it should be accompanied by a separate BIP. The field must be added to the field listing tables in the Specification section.
from this follows that new fields should be to be added both as new separate BIP and to the table in this BIP-174, with a reference to a dedicated BIP (like it was done for the taproot and hash preimage keys).
Updated proposal posted to bitcoin-dev mail list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019761.html
After discussion there I will update this PR with the proposal
@apoelstra, @achow101 did a PR here with a new BIP proposal https://github.com/bitcoin/bips/pull/1293.
I assume once #1293 will get merged this one still to be added to the main PSBT BIPs (I will update it then)
