Skip to content

Commit be59b4f

Browse files
luke-jrluke-jr
authored
Merge pull request bitcoin#1293 from BP-WG/bip/p2c
BIP 372: Pay-to-contract tweak fields for PSBT
2 parents 0eb216c + d7888e5 commit be59b4f

File tree

3 files changed

+199
-1
lines changed

3 files changed

+199
-1
lines changed

‎README.mediawiki

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1065,6 +1065,13 @@ Those proposing changes should consider that ultimately consent may rest with th
10651065
| Standard
10661066
| Draft
10671067
|-
1068+
| [[bip-0372.mediawiki|372]]
1069+
| Applications
1070+
| Pay-to-contract tweak fields for PSBT
1071+
| Maxim Orlovsky
1072+
| Standard
1073+
| Draft
1074+
|-
10681075
| [[bip-0380.mediawiki|380]]
10691076
| Applications
10701077
| Output Script Descriptors General Operation

‎bip-0372.mediawiki

Lines changed: 191 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,191 @@
1+
<pre>
2+
BIP: 372
3+
Layer: Applications
4+
Title: Pay-to-contract tweak fields for PSBT
5+
Author: Maxim Orlovsky <[email protected]>
6+
Discussions-To: <[email protected]>
7+
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0372
8+
Status: Draft
9+
Type: Standards Track
10+
Created: 2022-01-16
11+
License: BSD-2-Clause
12+
Requires: BIP-174
13+
</pre>
14+
15+
==Introduction==
16+
17+
===Abstract===
18+
19+
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2
20+
that allow for pay-to-contract key tweaking data data to be included in a PSBT
21+
of any version. These will represent an extra-transaction information required
22+
for the signer to produce valid signatures spending previous outputs.
23+
24+
===Copyright===
25+
26+
This BIP is licensed under the 2-clause BSD license.
27+
28+
===Background===
29+
30+
Key tweaking is a procedure for creating a cryptographic commitment to some
31+
message using elliptic curve properties. The procedure uses the discrete log
32+
problem (DLP) to commit to an extra-transaction message. This is done by adding
33+
to a public key (for which the output owner knows the corresponding private key)
34+
a hash of the message multiplied on the generator point G of the elliptic curve.
35+
This produces a tweaked public key, containing the commitment. Later, in order
36+
to spend an output containing P2C commitment, the same commitment should be
37+
added to the corresponding private key.
38+
39+
This type of commitment was originally proposed as a part of the pay to contract
40+
concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity Wall
41+
[2] for the same purpose. Since that time multiple different protocols for P2C
42+
has been developed, including OpenTimeStamps [3], Elements sidechain P2C tweaks
43+
[4] and LNPBP-1 [5], used in for constructing Peter Todd's single-use-seals [6]
44+
in client-side-validation protocols like RGB.
45+
46+
===Motivation===
47+
48+
P2C outputs can be detected onchain and spent only if the output owner
49+
not just knows the corresponding original private key, but also is aware about
50+
P2C tweak applied to the public key. In order to produce a valid signature, the
51+
same tweak value must be added (modulo group order) to the original private key
52+
by a signer device. This represents a challenge for external signers, which may
53+
not have any information about such commitment. This proposal addresses this
54+
issue by adding relevant fields to the PSBT input information.
55+
56+
The proposal abstracts details of specific P2C protocols and provides universal
57+
method for spending previous outputs containing P2C tweaks, applied to the public
58+
key contained within any standard form of the <tt>scriptPubkey</tt>, including
59+
bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested witness v0
60+
P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs.
61+
62+
63+
==Design==
64+
65+
P2C-tweaked public keys are already exposed in the
66+
<tt>PSBT_IN_REDEEM_SCRIPT</tt>, <tt>PSBT_IN_WITNESS_SCRIPT</tt>,
67+
<tt>PSBT_IN_TAP_INTERNAL_KEY</tt> and <tt>PSBT_IN_TAP_LEAF_SCRIPT</tt> fields;
68+
the only information signer is needed to recognize which keys it should sign
69+
with is from which of the original keys they were generated. This is achieved by
70+
introducing new `PSBT_IN_P2C_TWEAK` field which has the original key as a field
71+
key and the tweak as a field value. The signer will recognize the keys which are
72+
available to it, apply the tweak to them and see in which scripts it was used --
73+
and use this information to apply tweaks for the corresponding private keys and
74+
produce valid signatures.
75+
76+
77+
==Specification==
78+
79+
The new per-input type is defined as follows:
80+
81+
{|
82+
! Name
83+
! <tt><keytype></tt>
84+
! <tt><keydata></tt>
85+
! <tt><keydata></tt> Description
86+
! <tt><valuedata></tt>
87+
! <tt><valuedata></tt> Description
88+
! Versions Requiring Inclusion
89+
! Versions Requiring Exclusion
90+
! Versions Allowing Inclusion
91+
|-
92+
| P2C Key Tweak
93+
| <tt>PSBT_IN_P2C_TWEAK = 0x19</tt>
94+
| <tt><pubkey></tt>
95+
| 33 bytes of compact public key serialization specifying to which of keys the
96+
P2C tweak may be applied (i.e. this MUST be a value of a public key before the
97+
tweak is applied). BIP-340 keys are serialized by appending `02`
98+
byte.<ref>'''Why compressed public keys are not distinguished from BIP-340
99+
public keys'''We follow the logic of BIP32 key derivation which does not
100+
performs that distinguishment. The type of the key is defined by the input type,
101+
and adding additional PSBT field type will just create the need for handling
102+
errors when the input type does not match the provided key type.</ref>
103+
| <tt><tweak></tt>
104+
| The 32 byte value which MUST be added to a private key to produce correct
105+
ECDSA and/or Schnorr signature ("key tweak"). Signers SHOULD remove this field
106+
after <tt>PSBT_IN_PARTIAL_SIG</tt> is constructed.
107+
|
108+
|
109+
| 0, 2
110+
| BIP-P2C
111+
|}
112+
113+
114+
==Security considerations==
115+
116+
The scope of this proposal is deliberately kept narrow; it addresses
117+
only spending of transaction outputs containing P2C tweaks - and does not
118+
addresses construction of a new P2C commitments or transactions containing them
119+
in their outputs.<ref>'''Why only spending of P2C tweaked outputs is covered'''
120+
P2C tweaks commit to external data, some of which may represent certain value
121+
(like in some sidechains, single-use-seal applications like RGB etc). Creation
122+
of such outputs much allow hardware devices to understand the structure of such
123+
extra-transaction data, which may be in different formats and constantly
124+
involve. Thus, this should be addresses with a separate standards (or be a
125+
vendor-based). The current proposal only touches the question of spending an
126+
output which contained previously created P2C commitment, which does not creates
127+
a new commitment and does not provides that kind of risk of extra-blockchain
128+
value loses.</ref>
129+
130+
131+
==Rationale==
132+
133+
<references/>
134+
135+
136+
==Compatibility==
137+
138+
The proposal is compatible with the existing consensus rules and does not
139+
require any of their modifications.
140+
141+
The proposed P2C PSBT fields provides sufficient information for creating a
142+
valid signatures for spendings of the following output types containing tweaked
143+
public keys:
144+
- bare scripts,
145+
- P2PK,
146+
- P2PKH,
147+
- P2SH,
148+
- witness v0 P2WPKH and P2WSH,
149+
- nested witness v0 P2WPKH-P2SH and P2WSH-P2SH,
150+
151+
Post-0 witness versions, including taproot outputs and future witness versions,
152+
may not be supported or covered by this BIP and may require addition of new
153+
fields to the PSBT inputs.
154+
155+
156+
==Reference implementation==
157+
158+
WIP
159+
160+
161+
==Acknowledgements==
162+
163+
Author is grateful to Andrew Poelstra, who provided an initial set of ideas
164+
and information on his previous work on the topic basing on which this standard
165+
was designed.
166+
167+
168+
==Test vectors==
169+
170+
TBD
171+
172+
173+
==References==
174+
175+
[1] Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the
176+
Pay-to-Contract Protocol. arXiv:1212.3257 \[cs.CR\]
177+
<https://arxiv.org/pdf/1212.3257.pdf>
178+
[2] Eternity Wall's "sign-to-contract" article.
179+
<https://blog.eternitywall.com/2018/04/13/sign-to-contract/>
180+
[3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed
181+
Timestamping with Bitcoin.
182+
<https://petertodd.org/2016/opentimestamps-announcement>
183+
[4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain
184+
Innovations with Pegged Sidechains (commit5620e43). Appenxix A.
185+
<https://blockstream.com/sidechains.pdf>;.
186+
[5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key
187+
tweaking: collision- resistant elliptic curve-based commitments.
188+
LNPBP-1 Standard.
189+
<https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0001.md>
190+
[6] Peter Todd. Single-use-seals. LNPBP-8 Standard.
191+
<https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0008.md>

‎scripts/buildtable.pl

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -127,7 +127,7 @@
127127
my $title_len = length($title);
128128
die "$fn has too-long TItle ($title_len > 44 char max)" if $title_len > 44 and not exists $TolerateTitleTooLong{$bipnum};
129129
} elsif ($field eq 'Author') {
130-
$val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn";
130+
$val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.-]+\.\w+)\>$/ or die "Malformed Author line in $fn";
131131
my ($authorname, $authoremail) = ($1, $2);
132132
$authoremail =~ s/(?<=\D)$bipnum(?=\D)/<BIPNUM>/g;
133133
$emails{$authorname}->{$authoremail} = undef;

0 commit comments

Comments
 (0)