1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BB687CC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Jun 2018 23:34:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f180.google.com (mail-ot0-f180.google.com
[74.125.82.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 264306B6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Jun 2018 23:34:42 +0000 (UTC)
Received: by mail-ot0-f180.google.com with SMTP id r18-v6so12778410otk.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Jun 2018 16:34:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=DXZ/Tr3UORTJfwvn2WJMHw6bvkHe1SQvKeuMtFJBca4=;
b=MzesoOoUZQoddy5g0owvcCObfJoY87tY4+IyOpv/vzCl5BJ6WrDOh3Thc233h63dV8
25Tgl4OtlD8ys/fNKcqFEZkvyVq/Wk6EtndKlMSGzERdD5ktW5qyx4GjxiEnNxLeUu5R
bvAzRaCyuL/um8Q/3ztu9tT0RecwW4ttYNQV1wSKXQ6LU4IkHgHp//Zy73Cou1q0vuwQ
d7D/2vzD90vyqFFNrzcjtdiWH5OP/kttCqt9selwQEY8RoF+o0geH8mtIbjfsgMdCbJb
FPsL3MpTbUFjepcwDUXA5gemBXAZwYemSDxv8g5+Y1/na7XjNyRYFNKsKapC8oS0xyiL
Ps+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=DXZ/Tr3UORTJfwvn2WJMHw6bvkHe1SQvKeuMtFJBca4=;
b=bF1ZSUy5QqDBKxTS9DAo2iAlEm/qZ2ThWI6nt0aMo9znJhTtR6xqYqVZpT0UgivHKg
1t3mQCfQ5+YYf4nKXIXU7S1dgdK6DjrssHo3g+ZQwg99VxDTprUF33uE4as7B10R2yRO
+BZq2D0z6FMt0zUkxy0wgFu+OROBAl8p+8/lu/G+FiEGDwrDVLiGQ6Ud6psF3dai1xjL
kkGU6E/VAFNxzAXoVORxLwiGazE4lzjPJXlTjyA/NWtK6q5ZkklkZo1MGYr2+iTHaXPI
5bgR21eCf2uObqv2VWTnF2fJisAczFyN9QI2U4U4wLkIXwoh6+qU++uu69O7j+Sc384v
Ie9w==
X-Gm-Message-State: APt69E2Lum0UDov2rllVGwmp+jz6NW5tyIJpDsv6dOd4tOp/u+TdannF
tLBdDfHtklVh++tfm8w1+zFCb9jQPPQ3DDGDg6ADEycQ
X-Google-Smtp-Source: ADUXVKLuzMCDR+sQ+GI2mb1S8TpH0W72HA1vvfgAgXmdz9/1PMH3PSDbBQxPXvm2D5VDfy1lqC79YpGpJ0sG+fFhPko=
X-Received: by 2002:a9d:2f91:: with SMTP id
r17-v6mr2457734otb.356.1529105680870;
Fri, 15 Jun 2018 16:34:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 16:34:40
-0700 (PDT)
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Fri, 15 Jun 2018 16:34:40 -0700
Message-ID: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] BIP 174 thoughts
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2018 23:34:42 -0000
Hello all,
given some recent work and discussions around BIP 174 (Partially
Signed Bitcoin Transaction Format) I'd like to bring up a few ideas.
First of all, it's unclear to me to what extent projects have already
worked on implementations, and thus to what extent the specification
is still subject to change. A response of "this is way too late" is
perfectly fine.
So here goes:
* Key-value map model or set model.
This was suggested in this thread:
https://twitter.com/matejcik/status/1002618633472892929
The motivation behind using a key-value model rather than a simple
list of records was that PSBTs can be duplicated (given to multiple
people for signing, for example), and merged back together after
signing. With a generic key-value model, any implementation can remove
the duplication even if they don't understand fields that may have
been added in future extensions.
However, almost the same can be accomplished by using the simpler set
model (the file consists of a set of records, with no duplication
allowed). This would mean that it would technically be legal to have
two partial signatures with the same key for the same input, if a
non-deterministic signer is used.
On the other hand, this means that certain data currently encoded
inside keys can be dropped, reducing the PSBT size. This is
particularly true for redeemscripts and witnessscripts, as they can
just be computed by the client when deserializing. The two types could
even be merged into just "scripts" records - as they don't need to be
separated based on the way they're looked up (Hash160 for P2SH, SHA256
for P2WSH). The same could be done for the BIP32 derivation paths,
though this may be expensive, as the client would need to derive all
keys before being able to figure out which one(s) it needs.
One exception is the "transaction" record, which needs to be unique.
That can either be done by adding an exception ("there can only be one
transaction record"), or by encoding it separately outside the normal
records (that may also be useful to make it clear that it is always
required).
* Ability for Combiners to verify two PSBT are for the same transaction
Clearly two PSBTs for incompatible transactions cannot be combined,
and this should not be allowed.
It may be easier to enforce this if the "transaction" record inside a
PSBT was required to be in a canonical form, meaning with empty
scriptSigs and witnesses. In order to do so, there could be per-input
records for "finalized scriptSig" and "finalized witness". Actually
placing those inside the transaction itself would only be allowed when
all inputs are finalized.
* Optional signing
I think all operation for the Signer responsibility should be
optional. This will inevitably lead to incompatibilities, but with the
intent of being forward compatible with future developments, I don't
think it is possible to require every implementation to support the
same set of scripts or contracts. For example, some signers may only
implement single-key P2PKH, or may only support signing SegWit inputs.
It's the user's responsibility to find compatible signers (which is
generally not an issue, as the different participants in a setup
necessarily have this figured out before being able to create an
address). This does mean that there can't be an unconditional test
vector that specifies the produced signature in certain circumstances,
but there could be "For implementations that choose to implement
signing for P2PKH inputs using RFC6979, the expected output given
input X and access to key Y is Z".
On the other hand, the Combiner and Finalizer roles can probably be
specified much more accurately than they are now.
* Derivation from xpub or fingerprint
For BIP32 derivation paths, the spec currently only encodes the 32-bit
fingerprint of the parent or master xpub. When the Signer only has a
single xprv from which everything is derived, this is obviously
sufficient. When there are many xprv, or when they're not available
indexed by fingerprint, this may be less convenient for the signer.
Furthermore, it violates the "PSBT contains all information necessary
for signing, excluding private keys" idea - at least if we don't treat
the chaincode as part of the private key.
For that reason I would suggest that the derivation paths include the
full public key and chaincode of the parent or master things are
derived from. This does mean that the Creator needs to know the full
xpub which things are derived from, rather than just its fingerprint.
* Generic key offset derivation
Whenever a BIP32 derivation path does not include any hardened steps,
the entirety of the derivation can be conveyed as "The private key for
P is equal to the private key for Q plus x", with P and Q points and x
a scalar. This representation is more flexible (it also supports
pay-to-contract derivations), more efficient, and more compact. The
downside is that it requires the Signer to support such derivation,
which I don't believe any current hardware devices do.
Would it make sense to add this as an additional derivation method?
* Hex encoding?
This is a very minor thing. But presumably there will be some standard
way to store PSBTs as text for copy-pasting - either prescribed by the
spec, or de facto. These structures may become pretty large, so
perhaps it's worth choosing something more compact than hexadecimal -
for example Base64 or even Z85 (https://rfc.zeromq.org/spec:32/Z85/).
Cheers,
--
Pieter
|
