PSBT: Add pay-to-contract tweaks to tx inputs

dr-orlovsky commented at 0:10 am on November 21, 2021: contributor

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

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.

b76307bd81

Rose2161 approved

apoelstra commented at 2:40 pm on December 5, 2021: contributor

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).

achow101 commented at 8:59 pm on December 9, 2021: member

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

in bip-0174.mediawiki:520 in b76307bd81

515+|
516+| 0, 2
517+| 174
518+|-
519+| Taproot Internal P2C Tweak
520+| <tt>PSBT_IN_INTERNAL_P2C_TWEAK = 0x1b</tt>

achow101 commented at 9:02 pm on December 9, 2021:

The difference between this and PSBT_IN_TAP_P2C_TWEAK is not clear to me. ISTM this is for the internal key specifically, but the same effect can be achieved by specifying the internal key in PSBT_IN_TAP_P2C_TWEAK.

dr-orlovsky commented at 9:08 am on January 11, 2022:

Agree, good point

in bip-0174.mediawiki:511 in b76307bd81

506+| 174
507+|-
508+| Taproot Per-key P2C Tweak
509+| <tt>PSBT_IN_TAP_P2C_TWEAK = 0x1a</tt>
510+| <tt><xonlypubkey></tt>
511+| 32 bytes of public key specifying to which of keys tweak must be applied (i.e. this MUST be a value of a public key before the tweak is applied)

achow101 commented at 9:04 pm on December 9, 2021:

Does there need to be any consideration for keys in leaf scripts?

dr-orlovsky commented at 9:07 am on January 11, 2022:

I expect this to be a bad practice: the commitment must be singular per output (for instance to prevent double spends in second-layer systems like RGB), so allowing multiple tweaks in the same output is a security risk.

apoelstra commented at 2:34 pm on January 11, 2022:

I would like to support keys in leaf scripts (and arbitrary numbers of tweaks on arbitrary sets of keys). If the possibility is a security risk for some other protocol there is nothing that PSBT can do about it.

dr-orlovsky commented at 2:36 pm on January 11, 2022:

Ok, probably I was overcautious.

Actually there is no risk in spending P2C output, since the commitment is produced not at the spending time.

dr-orlovsky commented at 10:02 am on January 16, 2022:

@apoelstra what do you mean by “tweaks on arbitrary sets of keys”:

the same tweak must be applied to each of the keys in the set;
the tweak must be applied to one and only one key (i.e. the sum of this keys commits to the tweak)?

dr-orlovsky commented at 10:28 pm on January 16, 2022:

I came to conclusion that even most complex cases can be covered by a quite simple setup - pls see my description in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019761.html

luke-jr added the label Proposed BIP modification on Dec 15, 2021

dr-orlovsky commented at 11:22 am on December 21, 2021: contributor

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

Rose2161 approved

luke-jr commented at 11:26 pm on January 15, 2022: member

BIP 174 is Final… should be a new BIP (or maybe part of PSBTv2 if it’s not done?)

dr-orlovsky commented at 8:53 am on January 16, 2022: contributor

@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).

dr-orlovsky commented at 10:29 pm on January 16, 2022: contributor

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

dr-orlovsky marked this as a draft on Jan 16, 2022

dr-orlovsky commented at 9:35 am on March 29, 2022: contributor

@apoelstra, @achow101 did a PR here with a new BIP proposal #1293.

luke-jr commented at 11:41 pm on May 5, 2022: member

Can this PR be closed?

dr-orlovsky commented at 6:15 am on May 6, 2022: contributor

I assume once #1293 will get merged this one still to be added to the main PSBT BIPs (I will update it then)

murchandamus commented at 8:02 pm on April 26, 2024: contributor

The PR #1293 has been merged. What’s the status of this PR?

dr-orlovsky commented at 3:03 pm on April 27, 2024: contributor

Will update next week.

murchandamus added the label PR Author action required on May 8, 2024

5twelve approved

jonatack commented at 3:26 pm on August 7, 2024: member

Pinging @dr-orlovsky for update.

murchandamus commented at 8:20 pm on November 14, 2024: contributor

I am closing this pull request, because it has not made progress in over two years since the prerequisites for further steps had been met, and two requests for updates six and three months ago have been outstanding. If you are still working on this project, please request reopening or open a new pull request.

murchandamus closed this on Nov 14, 2024

PSBT: Add pay-to-contract tweaks to tx inputs #1239