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 CDF01D0A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Jul 2018 19:09:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com
[209.85.218.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3CD4978F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Jul 2018 19:09:32 +0000 (UTC)
Received: by mail-oi0-f51.google.com with SMTP id w126-v6so12439097oie.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 04 Jul 2018 12:09:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=smRrOI2SDkVyTYyHBKpQL7+OmHdkY9BfWyZgWBPs2Ug=;
b=tk0CdQhFNIAwr3e25EWudNW3GPXYUtLshOI/lacrjjHCvlcGBhRGuIlAITaUJf3of3
w1mlnPnbjKd3bvQRy2HFdigag/6xo9HFNuuHJF3zbTquIigcQjSEKbiE2B07ucmO7uqv
rtIkLm3618QMYMA+heqAmNAXYOLXtdKUEqQFaLtak4SaqOjHvFndQTENnQW4FHXB9Mca
ZFlBFIFRcYm4w+iA3xcBTKUxmwFaDvduJ+GvPbVHTi/4pUkyvCsLPo6Y84qvCw5EvolX
DBA1+CQFhF5SL4Nypi3xRvtTbxjaR9J6UTdL2dT3muQXRYsj5Eev6AdNfYGVAVFsk4M4
UDnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=smRrOI2SDkVyTYyHBKpQL7+OmHdkY9BfWyZgWBPs2Ug=;
b=Uemb3/XMKN0HHrZb4czog6ia0+OpvrVudrY6K2icj8HomVC5OSmv6lfMBPhOZPuKNs
FecrQ8tjT7N6KRx8xvAWBqaz51XJj/u22/Q134BwQBWqGBpv6b7aOCrIFv9sR/pRWJ16
TDq7cLgYK/INUrzX9eUxNHLCTyrdUSIZ7DaoEL0+3HPD3J4pWckPcqm11dRuSW9dNCDO
m6MBZAPEs1fD+tccrR1MBf6h/P79gyUeuyYnDBlZ7zACnRCrew1TdBiETHjIgZbbULkX
N3ZaAjU5foJ/0FNrE1zF/KkD3ivRgH0k1Ex9pN7WGEcrsrypcy5ydnSqK5GutMZs+2m8
65fQ==
X-Gm-Message-State: APt69E28ErqOVSgNG85LVHFQZP58fqN5R1OOZ8LGgLvZlgh6Z1jcKDxI
pFzg8+IKPGbkc5Hah5PzY8JIxXa1IIBr1rNmhS9C0Q==
X-Google-Smtp-Source: AAOMgpdjwdD1hsHNYMt51AfnpeVDV+y4jwG36BKH8HE08wD9o7t7r8V+BF/HqyKPdjWKOxLNFVA32erc2uUMQGK9+aw=
X-Received: by 2002:aca:670c:: with SMTP id
z12-v6mr3582972oix.76.1530731371258;
Wed, 04 Jul 2018 12:09:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP;
Wed, 4 Jul 2018 12:09:29 -0700 (PDT)
In-Reply-To: <c7a4476b-8643-3ddd-723b-1ff8b8910e36@satoshilabs.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
<ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>
<f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com>
<TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com>
<c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com>
<CAPg+sBhhYuMi6E1in7wZovX7R7M=450cm6vxaGC1Sxr=cJAZsw@mail.gmail.com>
<881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com>
<CAPg+sBg4MCOoMDBVQ2eZ=p3iS3dq506Jh4vUNBmmM20a6uCwYw@mail.gmail.com>
<95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com>
<RdSjdFhvANrG9ve8bXVnqs68ih5_iVK11jdOAL6WoMI2358TdylR3H2SyGHQfByKwMYYOfIJIOq0l6clYf-az8_D_D-D7cByzqbyYt1nV4c=@achow101.com>
<c7a4476b-8643-3ddd-723b-1ff8b8910e36@satoshilabs.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 4 Jul 2018 12:09:29 -0700
Message-ID: <CAPg+sBjczKB-tvGTpsDr8qDwfh6b_8M-2AdCwHR+DSC8pwY92Q@mail.gmail.com>
To: matejcik <jan.matejek@satoshilabs.com>
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Wed, 04 Jul 2018 19:09:32 -0000
On Wed, Jul 4, 2018 at 6:19 AM, matejcik <jan.matejek@satoshilabs.com> wrote:
> hello,
>
> we still have some concerns about the BIP as currently proposed - not
> about the format or data contents, but more about strictness and
> security properties. I have raised some in the previous e-mails, but
> they might have been lost in the overall talk about format.
>
> * Choosing from duplicate keys when combining.
> We believe that "choose whichever value it wishes" is not a good
> resolution strategy. We propose to either change this to "in case of
> conflicts, software MUST reject the conflicting PSBTs", or explain in
> more detail why picking at random is a safe choice.
Outlawing conflicting values would imply forcing all Signers to
implement fixed deterministic nonce generation, which I don't think it
very desirable. Otherwise PSBTs that got copied and signed and
combined again may fail. So I think we should see it the other way: we
choose the keys in such a way that picking arbitrarily is safe. If
there really is a future extension for which it would not be the case
that picking arbitrarily is acceptable, more data can be moved to the
keys, and leave the actual resolution strategy to the Finalizer. That
way Combiners can remain dumb and not need script-specific logic in
every interaction.
An alternative would be to have a fixed resolution strategy (for
example, when combining multiple PSBTs, pick the value from the first
one that has a particular key set), but I don't think this adds very
much - if picking the first is fine, picking a arbitrary one should be
fine too.
> * Signing records with unknown keys.
> There's been some talk about this at start, but there should be a clear
> strategy for Signers when unknown fields are encountered. We intend to
> implement the rule: "will not sign an input with any unknown fields
> present".
> Maybe it is worth codifying this behavior in the standard, or maybe
> there should be a way to mark a field as "optional" so that strict
> Signers know they can _safely_ ignore the unknown field.
Can you envision a situation in which this is needed? In every
scenario I can come up with, the worst that can happen is that the
resulting signature is just invalid. For example, if PSBT existed
before segwit, and then was later extended to support it, a pre-segwit
signer would not recognize that BIP143 would need to be used for
segwit inputs, and produce signatures using the old sighashing
algorithm. The result is just an invalid signature.
I believe that what you're trying to accomplish is preventing signing
something you don't understand, but that's an independent issue.
Signers generally will want to inspect the transaction they're
signing, or ask for confirmation w.r.t. fees or payment destinations
involved. The case where unknown fields are present for a reason you'd
want to withhold signing for will generally also just be the situation
where you don't understand the transaction you're signing.
Here is (perhaps far fetched) example of why it may not be desirable
to reject unknown fields when signing. Imagine an extension is defined
which adds pay-to-contract derivation for keys (Q = P + H(Q||C)G);
this would be a field similar to the current BIP32 derivation one, but
instead give a base key P and a contract C. Now say there is a 2-of-2
multisig in which you're one signer, and the other signer is (unknown
to you) using P2C. After the other party Updating, the input would
contain a P2C field which you don't understand - but it also isn't
something you care about or affects you.
I would not be opposed to having fields with an explicit flag bit that
says "Don't sign if you don't understand this", but I expect that that
can also be left for future extensions.
> * Fields with empty keys.
> This might be inferred from the definition, but is probably worth
> spelling out explicitly: If a field definition states that the key data
> is empty, an implementation MUST enforce this and reject PSBTs that
> contain non-empty data.
> We suggest adding something to the effect of:
> "If a key or value data in a field doesn't match the specified format,
> the PSBT is invalid. In particular, if key data is specified as "none"
> but the key contains data beyond the type specifier, implementation MUST
> reject the PSBT."
> (not sure about the languge, this should of course allow processing
> unknown fields)
Completely agree here. Any implementation that understands a
particular field must enforce whatever structure the field is known to
have.
> * "Combiner can detect inconsistencies"
> Added in response to this comment [1], the current wording looks like
> it's describing what the Combiner is _capable of_, as opposed to
> prescribing what the combiner is _allowed to_ do.
> We suggest changing to something like:
> "For every field type that the Combiner understands, it MAY also refuse
> to combine PSBTs that have inconsistencies in that field, or cause a
> conflict when combined."
Agree, just because Combiners are expected to work correctly on
unknown fields doesn't mean they can't enforce extra consistency
checks on known fields.
Cheers,
--
Pieter
|
