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
|
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 4FF33EEF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Jul 2018 18:27:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com
[209.85.218.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C6EE77E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Jul 2018 18:27:13 +0000 (UTC)
Received: by mail-oi0-f46.google.com with SMTP id k81-v6so51018385oib.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 Jul 2018 11:27:13 -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=X0E9+SjfvCmHj61MOeh+r/kHaDgUsPnVhE22xl+oJL0=;
b=qnwrclfxfyiM6BLMb9bSwCQCuayLCSojfIa69iI4yVWSCy8jM1v32bGq2zPnEUuCLm
3kmLy4B6MkDgbwvRUU3Jlq2pQfaNoa4/vXe+i/X8cz9PxXvauMOZ8rwhnYmZMkbyFunu
YOkSoXncbcrAeuNCq42996MDp5PqyJRgVdbrKpGpO+aKQRuJ6J7y71fddFdh7M3QS5Hl
HKOQ3M9G/4w2S1rgoP88tlZVj7R69kqauBa6Mn8N9znQg1oZdb/vben2gfSQNVf3uiaX
GsrZOKfCK45/chtvy/vccRegvxwxSaTTBwk5sIugnpVgWVxM8Xcs4a5SI1HaLkq2XIoj
AQYA==
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=X0E9+SjfvCmHj61MOeh+r/kHaDgUsPnVhE22xl+oJL0=;
b=PzZkPbnZcP/92B3kt3gRydYaS4VWd9L5PlOeXi3tDXXPCQi9o+nW1H7f9qQ1zLKSuZ
qZqcNZW+318UinV2dk0MjmAIG0hWGF/pcbQlcKrXryv/eL3MG//Z8k9z5jIP8GONSbup
h9oATzhbjaQ/aWGCKog8Nt49LGRVIn1rl8I8EBI5mLVqALV8oqqnZlqRi8vLyydpT1Xq
UrmoNAyjARea5C+AWTGW9UwRRC52r3QKUEYoTUJqhUv3ma3mx4pGgcEY4mXt5yPDCL3k
s8vrK316SwmgWCAdc6m8X3jovE8qXmkZd+RqAci9O1DCgXbSKzDmqAOFA/gA83ZqydiG
n9oQ==
X-Gm-Message-State: AOUpUlEO2uatECb2L63hltgDU+BpKmafryvBennTq/NVQuPvFZswPGTz
6uNJbxTXIjuaEb4BJIhkGhwjpIGW0cfBUQEIwPM=
X-Google-Smtp-Source: AAOMgpc4p5f5EhH6OgEPjsUUJC+oIe/M04P2Xk8oYcs5ocYI7eHELTm2QR1lBKPlVtUgx2E6xXf5tPn0jrWyZGAhQU4=
X-Received: by 2002:aca:5003:: with SMTP id e3-v6mr450693oib.89.1531333633091;
Wed, 11 Jul 2018 11:27:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 11:27:11
-0700 (PDT)
In-Reply-To: <797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.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>
<CAPg+sBjczKB-tvGTpsDr8qDwfh6b_8M-2AdCwHR+DSC8pwY92Q@mail.gmail.com>
<d1cc06c5-1d75-902a-1f2b-e5352c862fd6@satoshilabs.com>
<CAPg+sBi1Rt_V1V0K50RN-c6wr8hW+5OYWx4aR-Kh8Dp-U0LLdA@mail.gmail.com>
<797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 11 Jul 2018 11:27:11 -0700
Message-ID: <CAPg+sBi0zqpUka_YLDAgh1WHbYmXCdRyb=Givz-k1X=L9hV+Lw@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, 11 Jul 2018 18:27:15 -0000
On Tue, Jul 10, 2018 at 5:10 AM, matejcik <jan.matejek@satoshilabs.com> wrote:
> On 6.7.2018 00:06, Pieter Wuille wrote:> The only case where "malicious"
> conflicting values can occur is when
>> one of the Signers produces an invalid signature, or modifies any of
>> the other fields already present in the PSBT for consumption by
>> others. If this were an issue, it would be an issue regardless of the
>> Combiner's operation, as in topology A no Combiner is even present.
>> This is generally true I think - Combiners can always be replaced with
>> just a different (and possibly less parallel) topology of data flow.
>
> This is an interesting thesis, and also an unspoken assumption ISTM. It
> seems worth adding something like this to the spec:
> """
> In general, the result of Combiner combining two PSBTs from independent
> participants A and B should be functionally equivalent to a result
> obtained from processing the original PSBT by A and then B in a sequence.
> or, for participants performing fA(psbt) and fB(psbt):
> Combine(fA(psbt), fB(psbt)) == fA(fB(psbt)) == fB(fA(psbt))
> """
Adding that sounds like a good idea, indeed.
>> The bottom line is that a Combiner which picks arbitrarily in case of
>> conflicts will never end up with something worse than what you already
>> need to deal with. If you disregard the case of invalid fields
>> (because the result will just be an invalid transaction), then any
>> choice the Combiner makes is fine, because all the values it can pick
>> from are valid.
>
> This sounds reasonable and IMHO it would be good to have a summary of
> this argument in the Rationale section.
Sounds good.
>> If you're worried about attack surface, I don't believe rejecting
>> invalid fields ever matters. An attacker can always drop the fields
>> you don't understand before giving you the PSBT, making your behavior
>> identical to one where you'd have ignore those fields in the first
>> place.
>
> I'm reluctant to sign an input with unknown data, on the premise that there could be *anything* in that data
But the point is: you are not signing an input with unknown data. You
are signing your own interpretation (since you compute the sighash
yourself), which doesn't include what you don't understand. If that
interpretation doesn't match reality, the signature is at worst
useless. Who cares that someone added information about a transaction
that doesn't affect what you sign?
> We are most likely to implement the "do not sign with unknown fields"
> rule in any case (technically a whitelist of "known OK" field types),
> and resolve potential problems as they arise. I raised this point mainly
> because I think discussing this explicitly in the spec is beneficial: a
> distinction between mandatory and optional fields is one way, mentioning
> or prescribing possible signing strategies is another.
I don't think that's a particularly useful policy, but certainly
Signers are allowed to implement any policy they like about what they
accept in signing.
Cheers,
--
Pieter
|
