<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=BIP_0372</id>
	<title>BIP 0372 - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=BIP_0372"/>
	<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=BIP_0372&amp;action=history"/>
	<updated>2026-05-01T20:05:39Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.43.8</generator>
	<entry>
		<id>https://en.bitcoin.it/w/index.php?title=BIP_0372&amp;diff=70250&amp;oldid=prev</id>
		<title>934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9636d9c6831ff96a/bip-0372.mediawiki</title>
		<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=BIP_0372&amp;diff=70250&amp;oldid=prev"/>
		<updated>2024-05-31T04:54:08Z</updated>

		<summary type="html">&lt;p&gt;Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9636d9c6831ff96a/bip-0372.mediawiki&lt;/p&gt;
&lt;table style=&quot;background-color: #fff; color: #202122;&quot; data-mw=&quot;interface&quot;&gt;
				&lt;col class=&quot;diff-marker&quot; /&gt;
				&lt;col class=&quot;diff-content&quot; /&gt;
				&lt;col class=&quot;diff-marker&quot; /&gt;
				&lt;col class=&quot;diff-content&quot; /&gt;
				&lt;tr class=&quot;diff-title&quot; lang=&quot;en&quot;&gt;
				&lt;td colspan=&quot;2&quot; style=&quot;background-color: #fff; color: #202122; text-align: center;&quot;&gt;← Older revision&lt;/td&gt;
				&lt;td colspan=&quot;2&quot; style=&quot;background-color: #fff; color: #202122; text-align: center;&quot;&gt;Revision as of 04:54, 31 May 2024&lt;/td&gt;
				&lt;/tr&gt;&lt;tr&gt;&lt;td colspan=&quot;2&quot; class=&quot;diff-lineno&quot; id=&quot;mw-diff-left-l21&quot;&gt;Line 21:&lt;/td&gt;
&lt;td colspan=&quot;2&quot; class=&quot;diff-lineno&quot;&gt;Line 21:&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;br&gt;&lt;/td&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;br&gt;&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2&lt;/div&gt;&lt;/td&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2&lt;/div&gt;&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td class=&quot;diff-marker&quot; data-marker=&quot;−&quot;&gt;&lt;/td&gt;&lt;td style=&quot;color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;that allow for pay-to-contract key tweaking &lt;del style=&quot;font-weight: bold; text-decoration: none;&quot;&gt;data &lt;/del&gt;data to be included in a PSBT&lt;/div&gt;&lt;/td&gt;&lt;td class=&quot;diff-marker&quot; data-marker=&quot;+&quot;&gt;&lt;/td&gt;&lt;td style=&quot;color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;that allow for pay-to-contract key tweaking data to be included in a PSBT&lt;/div&gt;&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;of any version. These will represent an extra-transaction information required&lt;/div&gt;&lt;/td&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;of any version. These will represent an extra-transaction information required&lt;/div&gt;&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;for the signer to produce valid signatures spending previous outputs.&lt;/div&gt;&lt;/td&gt;&lt;td class=&quot;diff-marker&quot;&gt;&lt;/td&gt;&lt;td style=&quot;background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;&quot;&gt;&lt;div&gt;for the signer to produce valid signatures spending previous outputs.&lt;/div&gt;&lt;/td&gt;&lt;/tr&gt;

&lt;!-- diff cache key db_bitcoin_en:diff:1.41:old-69479:rev-70250:php=table --&gt;
&lt;/table&gt;</summary>
		<author><name>934</name></author>
	</entry>
	<entry>
		<id>https://en.bitcoin.it/w/index.php?title=BIP_0372&amp;diff=69479&amp;oldid=prev</id>
		<title>934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/40aef277672e28af/bip-0372.mediawiki</title>
		<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=BIP_0372&amp;diff=69479&amp;oldid=prev"/>
		<updated>2022-09-29T22:56:39Z</updated>

		<summary type="html">&lt;p&gt;Update BIP text with latest version from https://github.com/bitcoin/bips/blob/40aef277672e28af/bip-0372.mediawiki&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;{{bip}}&lt;br /&gt;
{{BipMoved|bip-0372.mediawiki}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  BIP: 372&lt;br /&gt;
  Layer: Applications&lt;br /&gt;
  Title: Pay-to-contract tweak fields for PSBT&lt;br /&gt;
  Author: Maxim Orlovsky &amp;lt;orlovsky@lnp-bp.org&amp;gt;&lt;br /&gt;
  Discussions-To: &amp;lt;bitcoin-dev@lists.linuxfoundation.org&amp;gt;&lt;br /&gt;
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0372&lt;br /&gt;
  Status: Draft&lt;br /&gt;
  Type: Standards Track&lt;br /&gt;
  Created: 2022-01-16&lt;br /&gt;
  License: BSD-2-Clause&lt;br /&gt;
  Requires: BIP-174&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Introduction==&lt;br /&gt;
&lt;br /&gt;
===Abstract===&lt;br /&gt;
&lt;br /&gt;
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2&lt;br /&gt;
that allow for pay-to-contract key tweaking data data to be included in a PSBT&lt;br /&gt;
of any version. These will represent an extra-transaction information required&lt;br /&gt;
for the signer to produce valid signatures spending previous outputs.&lt;br /&gt;
&lt;br /&gt;
===Copyright===&lt;br /&gt;
&lt;br /&gt;
This BIP is licensed under the 2-clause BSD license.&lt;br /&gt;
&lt;br /&gt;
===Background===&lt;br /&gt;
&lt;br /&gt;
Key tweaking is a procedure for creating a cryptographic commitment to some&lt;br /&gt;
message using elliptic curve properties. The procedure uses the discrete log&lt;br /&gt;
problem (DLP) to commit to an extra-transaction message. This is done by adding&lt;br /&gt;
to a public key (for which the output owner knows the corresponding private key)&lt;br /&gt;
a hash of the message multiplied on the generator point G of the elliptic curve.&lt;br /&gt;
This produces a tweaked public key, containing the commitment. Later, in order&lt;br /&gt;
to spend an output containing P2C commitment, the same commitment should be&lt;br /&gt;
added to the corresponding private key.&lt;br /&gt;
&lt;br /&gt;
This type of commitment was originally proposed as a part of the pay to contract&lt;br /&gt;
concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity Wall&lt;br /&gt;
[2] for the same purpose. Since that time multiple different protocols for P2C&lt;br /&gt;
has been developed, including OpenTimeStamps [3], Elements sidechain P2C tweaks&lt;br /&gt;
[4] and LNPBP-1 [5], used in for constructing Peter Todd&amp;#039;s single-use-seals [6]&lt;br /&gt;
in client-side-validation protocols like RGB.&lt;br /&gt;
&lt;br /&gt;
===Motivation===&lt;br /&gt;
&lt;br /&gt;
P2C outputs can be detected onchain and spent only if the output owner&lt;br /&gt;
not just knows the corresponding original private key, but also is aware about&lt;br /&gt;
P2C tweak applied to the public key. In order to produce a valid signature, the&lt;br /&gt;
same tweak value must be added (modulo group order) to the original private key&lt;br /&gt;
by a signer device. This represents a challenge for external signers, which may&lt;br /&gt;
not have any information about such commitment. This proposal addresses this&lt;br /&gt;
issue by adding relevant fields to the PSBT input information.&lt;br /&gt;
&lt;br /&gt;
The proposal abstracts details of specific P2C protocols and provides universal&lt;br /&gt;
method for spending previous outputs containing P2C tweaks, applied to the public&lt;br /&gt;
key contained within any standard form of the &amp;lt;tt&amp;gt;scriptPubkey&amp;lt;/tt&amp;gt;, including&lt;br /&gt;
bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested witness v0&lt;br /&gt;
P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Design==&lt;br /&gt;
&lt;br /&gt;
P2C-tweaked public keys are already exposed in the&lt;br /&gt;
&amp;lt;tt&amp;gt;PSBT_IN_REDEEM_SCRIPT&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;PSBT_IN_WITNESS_SCRIPT&amp;lt;/tt&amp;gt;,&lt;br /&gt;
&amp;lt;tt&amp;gt;PSBT_IN_TAP_INTERNAL_KEY&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;PSBT_IN_TAP_LEAF_SCRIPT&amp;lt;/tt&amp;gt; fields;&lt;br /&gt;
the only information signer is needed to recognize which keys it should sign&lt;br /&gt;
with is from which of the original keys they were generated. This is achieved by&lt;br /&gt;
introducing new `PSBT_IN_P2C_TWEAK` field which has the original key as a field&lt;br /&gt;
key and the tweak as a field value. The signer will recognize the keys which are&lt;br /&gt;
available to it, apply the tweak to them and see in which scripts it was used --&lt;br /&gt;
and use this information to apply tweaks for the corresponding private keys and&lt;br /&gt;
produce valid signatures.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Specification==&lt;br /&gt;
&lt;br /&gt;
The new per-input type is defined as follows:&lt;br /&gt;
&lt;br /&gt;
{|&lt;br /&gt;
! Name&lt;br /&gt;
! &amp;lt;tt&amp;gt;&amp;lt;keytype&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
! &amp;lt;tt&amp;gt;&amp;lt;keydata&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
! &amp;lt;tt&amp;gt;&amp;lt;keydata&amp;gt;&amp;lt;/tt&amp;gt; Description&lt;br /&gt;
! &amp;lt;tt&amp;gt;&amp;lt;valuedata&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
! &amp;lt;tt&amp;gt;&amp;lt;valuedata&amp;gt;&amp;lt;/tt&amp;gt; Description&lt;br /&gt;
! Versions Requiring Inclusion&lt;br /&gt;
! Versions Requiring Exclusion&lt;br /&gt;
! Versions Allowing Inclusion&lt;br /&gt;
|-&lt;br /&gt;
| P2C Key Tweak&lt;br /&gt;
| &amp;lt;tt&amp;gt;PSBT_IN_P2C_TWEAK = 0x19&amp;lt;/tt&amp;gt;&lt;br /&gt;
| &amp;lt;tt&amp;gt;&amp;lt;pubkey&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
| 33 bytes of compact public key serialization specifying to which of keys the&lt;br /&gt;
P2C tweak may be applied (i.e. this MUST be a value of a public key before the&lt;br /&gt;
tweak is applied). BIP-340 keys are serialized by appending `02`&lt;br /&gt;
byte.&amp;lt;ref&amp;gt;&amp;#039;&amp;#039;&amp;#039;Why compressed public keys are not distinguished from BIP-340&lt;br /&gt;
public keys&amp;#039;&amp;#039;&amp;#039;We follow the logic of BIP32 key derivation which does not&lt;br /&gt;
performs that distinguishment. The type of the key is defined by the input type,&lt;br /&gt;
and adding additional PSBT field type will just create the need for handling&lt;br /&gt;
errors when the input type does not match the provided key type.&amp;lt;/ref&amp;gt;&lt;br /&gt;
| &amp;lt;tt&amp;gt;&amp;lt;tweak&amp;gt;&amp;lt;/tt&amp;gt;&lt;br /&gt;
| The 32 byte value which MUST be added to a private key to produce correct&lt;br /&gt;
ECDSA and/or Schnorr signature (&amp;quot;key tweak&amp;quot;). Signers SHOULD remove this field&lt;br /&gt;
after &amp;lt;tt&amp;gt;PSBT_IN_PARTIAL_SIG&amp;lt;/tt&amp;gt; is constructed.&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
| 0, 2&lt;br /&gt;
| BIP-P2C&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Security considerations==&lt;br /&gt;
&lt;br /&gt;
The scope of this proposal is deliberately kept narrow; it addresses&lt;br /&gt;
only spending of transaction outputs containing P2C tweaks - and does not&lt;br /&gt;
addresses construction of a new P2C commitments or transactions containing them&lt;br /&gt;
in their outputs.&amp;lt;ref&amp;gt;&amp;#039;&amp;#039;&amp;#039;Why only spending of P2C tweaked outputs is covered&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
P2C tweaks commit to external data, some of which may represent certain value&lt;br /&gt;
(like in some sidechains, single-use-seal applications like RGB etc). Creation&lt;br /&gt;
of such outputs much allow hardware devices to understand the structure of such&lt;br /&gt;
extra-transaction data, which may be in different formats and constantly&lt;br /&gt;
involve. Thus, this should be addresses with a separate standards (or be a&lt;br /&gt;
vendor-based). The current proposal only touches the question of spending an&lt;br /&gt;
output which contained previously created P2C commitment, which does not creates&lt;br /&gt;
a new commitment and does not provides that kind of risk of extra-blockchain&lt;br /&gt;
value loses.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Rationale==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Compatibility==&lt;br /&gt;
&lt;br /&gt;
The proposal is compatible with the existing consensus rules and does not&lt;br /&gt;
require any of their modifications.&lt;br /&gt;
&lt;br /&gt;
The proposed P2C PSBT fields provides sufficient information for creating a&lt;br /&gt;
valid signatures for spendings of the following output types containing tweaked&lt;br /&gt;
public keys:&lt;br /&gt;
- bare scripts,&lt;br /&gt;
- P2PK,&lt;br /&gt;
- P2PKH,&lt;br /&gt;
- P2SH,&lt;br /&gt;
- witness v0 P2WPKH and P2WSH,&lt;br /&gt;
- nested witness v0 P2WPKH-P2SH and P2WSH-P2SH,&lt;br /&gt;
&lt;br /&gt;
Post-0 witness versions, including taproot outputs and future witness versions,&lt;br /&gt;
may not be supported or covered by this BIP and may require addition of new&lt;br /&gt;
fields to the PSBT inputs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Reference implementation==&lt;br /&gt;
&lt;br /&gt;
WIP&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Acknowledgements==&lt;br /&gt;
&lt;br /&gt;
Author is grateful to Andrew Poelstra, who provided an initial set of ideas&lt;br /&gt;
and information on his previous work on the topic basing on which this standard&lt;br /&gt;
was designed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Test vectors==&lt;br /&gt;
&lt;br /&gt;
TBD&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&lt;br /&gt;
[1] Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the&lt;br /&gt;
    Pay-to-Contract Protocol. arXiv:1212.3257 \[cs.CR\]&lt;br /&gt;
    &amp;lt;https://arxiv.org/pdf/1212.3257.pdf&amp;gt;&lt;br /&gt;
[2] Eternity Wall&amp;#039;s &amp;quot;sign-to-contract&amp;quot; article.&lt;br /&gt;
    &amp;lt;https://blog.eternitywall.com/2018/04/13/sign-to-contract/&amp;gt;&lt;br /&gt;
[3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed&lt;br /&gt;
    Timestamping with Bitcoin.&lt;br /&gt;
    &amp;lt;https://petertodd.org/2016/opentimestamps-announcement&amp;gt;&lt;br /&gt;
[4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain&lt;br /&gt;
    Innovations with Pegged Sidechains (commit5620e43). Appenxix A.&lt;br /&gt;
    &amp;lt;https://blockstream.com/sidechains.pdf&amp;gt;;.&lt;br /&gt;
[5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key&lt;br /&gt;
    tweaking: collision- resistant elliptic curve-based commitments.&lt;br /&gt;
    LNPBP-1 Standard.&lt;br /&gt;
    &amp;lt;https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0001.md&amp;gt;&lt;br /&gt;
[6] Peter Todd. Single-use-seals. LNPBP-8 Standard.&lt;br /&gt;
    &amp;lt;https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0008.md&amp;gt;&lt;/div&gt;</summary>
		<author><name>934</name></author>
	</entry>
</feed>