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
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A686F8E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 18:13:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com
[209.85.128.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 428C542B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 18:13:09 +0000 (UTC)
Received: by mail-wr0-f178.google.com with SMTP id k46so31106693wre.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 11:13:09 -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=eHR1celKo7KRWJAYYgV3fxaxjo337fJSmZx6Ecx36y4=;
b=s2z9Lco3D8LfHJ55w1bONXkRjaKYGSxz4B4h0C4HiAWPm+BvoMLscuosU73FngQhhU
FX8D1RXB3nkAj9pJm+Uk4ux/9RwrOPQ3choKnYKffygKhDwmqn1rgDXCcp+VOuL7joGG
qQUpVchTzD1bgzW+Y5oZG3NDho9XBiliqTwaFInmW29u1Fw0cysWIXxJX9az14Ex9qnN
nfqKTDQz/eBH9wr3pyjE0h4Z0Lg/lGK3A9iKHVG/AQxlwOZSaGPkK7LEdxTZ0t0HLTGm
0UCXe8/SDMrYNJ6q93zSjIwYSJtNa+laO/p4krBSxoXxqpCfFzH0zZObzvXHAeHdxAWt
+G0Q==
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=eHR1celKo7KRWJAYYgV3fxaxjo337fJSmZx6Ecx36y4=;
b=ab5LcJIgpCJ89pRIq4HcCjKRICD/dqxeh0O1JDAGNAS+cYtrbj5ipmuQ+fzaGReg9f
r/2GPlg7R0sdTBmp+BPlrwCQInUSPTQVs9MKd1rL+swiUckbwnLC4rsmvfcTfli0kJYL
oq7gqW5n0k8Xg/p/UtCv1vrvK6bvoRpAU5/bn95VgURN235tMZ9xgyrhIHRTNaazaZmQ
EQexWYkhd0GmwhNx/vTwveB6LLQUwdHN+dLmyXq4/S9dhJaHSy7p44JFn2A6hQZUr9wi
W0xA/hmOhNwAaQg87UGWQeIJUT2bUA0cfEtfc8IYAgdwY3ZT8tN1HVgi5xzkkH6YGx3i
qj6w==
X-Gm-Message-State: AHYfb5iW0IrMoLSW1t5UqLGs2zSZgwOFqq7vs15S94rSV5hWAWXIlzup
qdsOtp5RqBoTLBcdAK+h8NwvPZhU4eHt9CQ=
X-Received: by 10.80.134.131 with SMTP id r3mr8080859eda.29.1503339187746;
Mon, 21 Aug 2017 11:13:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.129.163 with HTTP; Mon, 21 Aug 2017 11:12:47 -0700 (PDT)
In-Reply-To: <CABaSBaxjGLmiM0+zTk2PoGTt1zEao-k0ADLkT47vx+mcnPACJw@mail.gmail.com>
References: <CAP6ruDR0GrLRNb4TTub+wqpwVPyzHggbomV48kLZU3tvubH73Q@mail.gmail.com>
<CABaSBaxjGLmiM0+zTk2PoGTt1zEao-k0ADLkT47vx+mcnPACJw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 21 Aug 2017 11:12:47 -0700
Message-ID: <CAB3F3Dv1kuJdu8veNUHa4b58TvWy=BT6zfxdhqEPBQ8rjDfWtA@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c0ac8433b3e0557476e7f"
Subject: Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin
Transaction (PSBT) format
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: Mon, 21 Aug 2017 18:13:09 -0000
--f403045c0ac8433b3e0557476e7f
Content-Type: text/plain; charset="UTF-8"
Some related thoughts and suggestion for an extension that kanzure
suggested I post here:
Hardware Wallet attacks by input ownership omission and fix
----------------------------------------------------------------------------------
So a while back I realized that to have HW wallets do safe automated
coinjoins(without any user interaction be sure there are no fee dumps or
handing money to others) you have to protect yourself from the case of
signing one set of inputs while the other owned set is hidden from the
device, then repeating the same action with the two sets reversed.
Note that there is no support for such a mode in HW wallets today, but
could possibly greatly increase liquidity of JoinMarket like systems.
First signing pass:
1 BTC (yours, host tells ledger about it) --------
> 1.5 BTC
1 BTC (yours, host fails to tell ledger about it)-
Second signing pass:
1 BTC (yours, host fails to tell ledger) ---------
> 1.5 BTC
1 BTC (yours, host tells ledger about it)---------
In this scenario, you sign the first input, thinking "great I'm getting 0.5
BTC for running coinjoin" when in reality this will simply be re-played
again later with the inputs switched, *costing* you 0.5 BTC. (Ledger
doesn't support "negative fees", but imagine more more inputs are included
that aren't yours.)
More recently I noticed a more common issue along the same lines:
With Segwit inputs, the entire transaction referred to in the prevout is
generally no longer included for HW wallet signing API. This greatly speeds
up signing since potentially multiple MBs of transactions are no longer
passed into the device, but comes with a cost: An attacker can claim
certain inputs' value is much lower than it actually is. In the first pass,
the host reports the first input's value properly, and the second as lower.
The signature on the first input will go through fine(value included in the
sighash is only for that input), then attacker prompts a restart of
signing, reporting the 2nd value properly, and first value improperly low,
which allows the attacker to report the same fee twice on the device. Both
signatures over each input are correct, but the user was prompted with an
invalid fee amount(too low).
To fix this I consulted with andytoshi and got something we think works for
both cases:
1) When a signing device receives a partially signed transaction, all
inputs must come with a ownership proof:
- For the input at address A, a signature over H(A || x) using the key for
A. 'x' is some private fixed key that only the signing device knows(most
likely some privkey along some unique bip32 path).
- For each input ownership proof, the HW wallet validates each signature
over the hashed message, then attempts to "decode" the hash by applying its
own 'x'. If the hash doesn't match, it cannot be its own input.
- Sign for every input that is yours
This at a minimum makes sure that the wallet's total "balance" will not go
down more than the reported fee.
Benefits:
- Still small memory footprint compared to legacy signing
- Allows user-interactionless coinjoins without putting funds at risk
- These proofs can be created at any time, collected at the front of any
CoinJoin like protocol.
- These proofs can be passed around as additional fields for Partially
Signed Bitcoin Transactions:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014838.html
On Sun, Aug 20, 2017 at 5:00 PM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Aug 18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> I would like to propose a standard format for unsigned and partially
>> signed transactions.
>>
>
> Just a quick note but perhaps you and other readers would find this thread
> (on hardware wallet BIP drafting) to be tangentially related and useful:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-August/013008.html
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--f403045c0ac8433b3e0557476e7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some related thoughts and suggestion for an extension that=
kanzure suggested I post here:<div><br></div><div><div>Hardware Wallet att=
acks by input ownership omission and fix</div><div>------------------------=
----------------------------------------------------------</div><div>So a w=
hile back I realized that to have HW wallets do safe automated coinjoins(wi=
thout any user interaction be sure there are no fee dumps or handing money =
to others) you have to protect yourself from the case of signing one set of=
inputs while the other owned set is hidden from the device, then repeating=
the same action with the two sets reversed.</div><div><br></div><div>Note =
that there is no support for such a mode in HW wallets today, but could pos=
sibly greatly increase liquidity of JoinMarket like systems.</div><div><br>=
</div><div>First signing pass:</div><div>1 BTC (yours, host tells ledger ab=
out it) --------</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 1.5 BTC</div><div=
>1 BTC (yours, host fails to tell ledger about it)-</div><div><br></div><di=
v>Second signing pass:</div><div><br></div><div>1 BTC (yours, host fails to=
tell ledger) ---------</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 1.5 BTC</d=
iv><div>1 BTC (yours, host tells ledger about it)---------</div><div><br></=
div><div>In this scenario, you sign the first input, thinking "great I=
'm getting 0.5 BTC for running coinjoin" when in reality this will=
simply be re-played again later with the inputs switched, *costing* you 0.=
5 BTC. (Ledger doesn't support "negative fees", but imagine m=
ore more inputs are included that aren't yours.)</div><div><br></div><d=
iv>More recently I noticed a more common issue along the same lines:</div><=
div><br></div><div>With Segwit inputs, the entire transaction referred to i=
n the prevout is generally no longer included for HW wallet signing API. Th=
is greatly speeds up signing since potentially multiple MBs of transactions=
are no longer passed into the device, but comes with a cost: An attacker c=
an claim certain inputs' value is much lower than it actually is. In th=
e first pass, the host reports the first input's value properly, and th=
e second as lower. The signature on the first input will go through fine(va=
lue included in the sighash is only for that input), then attacker prompts =
a restart of signing, reporting the 2nd value properly, and first value imp=
roperly low, which allows the attacker to report the same fee twice on the =
device. Both signatures over each input are correct, but the user was promp=
ted with an invalid fee amount(too low).</div><div><br></div><div>To fix th=
is I consulted with andytoshi and got something we think works for both cas=
es:</div><div><br></div><div>1) When a signing device receives a partially =
signed transaction, all inputs must come with a ownership proof:</div><div>=
- For the input at address A, a signature over H(A || x) using the key for =
A. 'x' is some private fixed key that only the signing device knows=
(most likely some privkey along some unique bip32 path).</div><div>- For ea=
ch input ownership proof, the HW wallet validates each signature over the h=
ashed message, then attempts to "decode" the hash by applying its=
own 'x'. If the hash doesn't match, it cannot be its own input=
.</div><div>- Sign for every input that is yours</div><div><br></div><div>T=
his at a minimum makes sure that the wallet's total "balance"=
will not go down more than the reported fee.</div><div><br></div><div>Bene=
fits:</div><div>- Still small memory footprint compared to legacy signing</=
div><div>- Allows user-interactionless coinjoins without putting funds at r=
isk</div><div>- These proofs can be created at any time, collected at the f=
ront of any CoinJoin like protocol.</div><div>- These proofs can be passed =
around as additional fields for Partially Signed Bitcoin Transactions: <a h=
ref=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/=
014838.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-A=
ugust/014838.html</a></div></div></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Sun, Aug 20, 2017 at 5:00 PM, Bryan Bishop via bit=
coin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Fri, Aug =
18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev <span dir=3D"ltr"><<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.<wbr>linuxfoundation.org</a>></span> wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I would like to pr=
opose a standard format for unsigned and partially signed transactions.=C2=
=A0</div></div></blockquote></span><div><br>Just a quick note but perhaps y=
ou and other readers would find this thread (on hardware wallet BIP draftin=
g) to be tangentially related and useful:<br><a href=3D"https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2016-August/013008.html" target=3D"_bl=
ank">https://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2016=
-August/013008.html</a><br><br></div></div><div class=3D"m_3051289811029518=
180gmail_signature">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"_=
blank">http://heybryan.org/</a><br><a href=3D"tel:(512)%20203-0507" value=
=3D"+15122030507" target=3D"_blank">1 512 203 0507</a></div>
</div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--f403045c0ac8433b3e0557476e7f--
|