summaryrefslogtreecommitdiff
path: root/a9/6333e35624e393050ee405cbbde2e4e091a11e
blob: f4a768214ae73ff01334701f9a97753b67be873c (plain)
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
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
Return-Path: <me@thomaskerin.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 774B49E7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Aug 2016 00:25:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from thomaskerin.io (static.204.212.9.5.clients.your-server.de
	[5.9.212.204])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8AD241CA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Aug 2016 00:25:38 +0000 (UTC)
Received: from [10.137.3.17] (tor-relay.m5i.uk [178.239.167.15])
	by thomaskerin.io (Postfix) with ESMTPSA id F035511981029
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Aug 2016 00:25:32 +0000 (UTC)
To: bitcoin-dev@lists.linuxfoundation.org
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
From: Thomas Kerin <me@thomaskerin.io>
Message-ID: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
Date: Wed, 17 Aug 2016 01:25:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Icedove/45.2.0
MIME-Version: 1.0
In-Reply-To: <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 17 Aug 2016 00:26:08 +0000
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
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, 17 Aug 2016 00:25:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N
Content-Type: multipart/mixed; boundary="iN0N0tFHgqOJln4tDXdFvgUfN4jRkpMhO"
From: Thomas Kerin <me@thomaskerin.io>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
References: <57B31EBC.1030806@jonasschnelli.ch>
 <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
In-Reply-To: <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>

--iN0N0tFHgqOJln4tDXdFvgUfN4jRkpMhO
Content-Type: multipart/alternative;
 boundary="------------025D8A9ED594D5FDC3F544C7"

This is a multi-part message in MIME format.
--------------025D8A9ED594D5FDC3F544C7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi all,

Thanks again Jonas for starting this!

I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascript code / using Core's debug
console / coinb.in

Happily the procedure is largely the same, though I would echo Jochen's
point that there needs to be a way to request an xpub/public key.

The redeemScript and witnessScript are also required fields for full
validation & signing a transaction input if it's P2SH, or just the
witnessScript if it's bare V0_P2WSH

Since the output amounts are required, so maybe instead provide
serialized TxOut's? or Utxo's i.e: [txid, vout, amount, scriptPubKey].

The protocol ought to be as stateless as possible - it can't be assumed
whether the redeemScript and other details will ever be saved on the
device - so perhaps provide the redeemScript + witnessScript as the
final fields on the Utxo structure above.

I do think it enables two important choices for bitcoin users:

* it might be preferable to provide your own xpub vs generating a brand
new HD key to potentially lose.

* you could leverage the services provided by [random example]
GreenAddress without necessarily having to rely on signing code provided
by them, and so end up only having to trust only one ECDSA
implementation when interacting with a wide number of services

All the best

Thomas

On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing.  A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware.  Do you plan to have this in a separate
> standard or should this also be included here?  Basically one needs one=

> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)=

> to prove that the amount really matches (this is not necessary for segw=
it)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary:  All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme.  So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other=

> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2s=
h
> transactions.  Is this always the scriptPubKey of the transaction outpu=
t
> that is spent by this input? For p2wsh nested in BIP16 p2sh transaction=
s
> there are three scripts
>
>     witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG=
>
>     scriptSig:    <0 <32-byte-hash>>
>                   (0x220020{32-byte-hash})
>     scriptPubKey: HASH160 <20-byte-hash> EQUAL
>                   (0xA914{20-byte-hash}87)
>  (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output.  Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
>   Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing.  A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware.  Do you plan to have this in a separate
> standard or should this also be included here?  Basically one needs one=

> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)=

> to prove that the amount really matches (this is not necessary for segw=
it)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary:  All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme.  So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other=

> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2s=
h
> transactions.  Is this always the scriptPubKey of the transaction outpu=
t
> that is spent by this input? For p2wsh nested in BIP16 p2sh transaction=
s
> there are three scripts
>
>     witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG=
>
>     scriptSig:    <0 <32-byte-hash>>
>                   (0x220020{32-byte-hash})
>     scriptPubKey: HASH160 <20-byte-hash> EQUAL
>                   (0xA914{20-byte-hash}87)
>  (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output.  Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
>   Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------025D8A9ED594D5FDC3F544C7
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p>Hi all,
    </p>
    <div class=3D"moz-forward-container">
      <p>Thanks again Jonas for starting this!<br>
      </p>
      I worked on a similar proposal a while back (never posted),
      approaching the same problem as if a merchant's website accepted
      xpubs/public keys, created multi-signature addresses, and wanted
      the user to easily sign offline instead of using some javascript
      code / using Core's debug console / coinb.in<br>
      <br>
      Happily the procedure is largely the same, though I would echo
      Jochen's
      point that there needs to be a way to request an xpub/public key.
      <br>
      <br>
      The redeemScript and witnessScript are also required fields for
      full validation &amp; signing a transaction input if it's P2SH, or
      just the witnessScript if it's bare V0_P2WSH<br>
      <br>
      Since the output amounts are required, so maybe instead provide
      serialized TxOut's? or Utxo's i.e: [txid, vout, amount,
      scriptPubKey]. <br>
      <br>
      The protocol ought to be as stateless as possible - it can't be
      assumed whether the redeemScript and other details will ever be
      saved on the device - so perhaps provide the redeemScript +
      witnessScript as the final fields on the Utxo structure above.<br>
      <br>
      I do think it enables two important choices for bitcoin users:<br>
      <br>
      * it might be preferable to provide your own xpub vs generating a
      brand new HD key to potentially lose.<br>
      <br>
      * you could leverage the services provided by [random example]
      GreenAddress without necessarily having to rely on signing code
      provided by them, and so end up only having to trust only one
      ECDSA implementation when interacting with a wide number of
      services<br>
      <br>
      All the best<br>
      <br>
      Thomas<br>
      <br>
      <div class=3D"moz-cite-prefix">On 08/16/2016 06:48 PM, Jochen
        Hoenicke via bitcoin-dev wrote:<br>
      </div>
      <blockquote
        cite=3D"mid:e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com"
        type=3D"cite">
        <pre wrap=3D"">Hello Jonas,

thanks for your efforts of writing the draft for the standard.

First, this only describes detached signing.  A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware.  Do you plan to have this in a separate
standard or should this also be included here?  Basically one needs one
operation: get xpub for an HD path.

=46rom a first read over the specification I found the following points
missing, that a fully checking hardware wallet needs to know:

- the amount spent by each input (necessary for segwit).
- the full serialized input transactions (without witness informations)
to prove that the amount really matches (this is not necessary for segwit=
)
- the position of the change output and its HD Path (to verify that it
really is a change output).
- For multisig change addresses, there are more extensive checks
necessary:  All inputs must be multisig addresses signed with public
keys derived from the same set of xpubs as the change address and use
the same "m of n" scheme.  So for multisig inputs and multisig change
address the standard should allow to give the parent xpubs of the other
public keys and their derivation paths.

It is also a bit ambiguous what the "inputscript" is especially for p2sh
transactions.  Is this always the scriptPubKey of the transaction output
that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
there are three scripts

    witness:      0 &lt;signature1&gt; &lt;1 &lt;pubkey1&gt; &lt;pubkey2&=
gt; 2 CHECKMULTISIG&gt;
    scriptSig:    &lt;0 &lt;32-byte-hash&gt;&gt;
                  (0x220020{32-byte-hash})
    scriptPubKey: HASH160 &lt;20-byte-hash&gt; EQUAL
                  (0xA914{20-byte-hash}87)
 (quoted from BIP-141).

In principle one could put witness and scriptSig (with "OP_FALSE" in
places of the signatures) in the raw transaction and make inputscript
always the scriptPubKey of the corresponding output.  Then one also
doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
nested in bip16 p2sh" transactions.

Regards,
  Jochen


</pre>
        <br>
        <fieldset class=3D"mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap=3D"">_______________________________________________
bitcoin-dev mailing list
<a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>
<a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" href=3D"https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
      </blockquote>
      <br>
    </div>
    <br>
    <div class=3D"moz-cite-prefix">On 08/16/2016 06:48 PM, Jochen Hoenick=
e
      via bitcoin-dev wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com"
      type=3D"cite">
      <pre wrap=3D"">Hello Jonas,

thanks for your efforts of writing the draft for the standard.

First, this only describes detached signing.  A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware.  Do you plan to have this in a separate
standard or should this also be included here?  Basically one needs one
operation: get xpub for an HD path.

=46rom a first read over the specification I found the following points
missing, that a fully checking hardware wallet needs to know:

- the amount spent by each input (necessary for segwit).
- the full serialized input transactions (without witness informations)
to prove that the amount really matches (this is not necessary for segwit=
)
- the position of the change output and its HD Path (to verify that it
really is a change output).
- For multisig change addresses, there are more extensive checks
necessary:  All inputs must be multisig addresses signed with public
keys derived from the same set of xpubs as the change address and use
the same "m of n" scheme.  So for multisig inputs and multisig change
address the standard should allow to give the parent xpubs of the other
public keys and their derivation paths.

It is also a bit ambiguous what the "inputscript" is especially for p2sh
transactions.  Is this always the scriptPubKey of the transaction output
that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
there are three scripts

    witness:      0 &lt;signature1&gt; &lt;1 &lt;pubkey1&gt; &lt;pubkey2&=
gt; 2 CHECKMULTISIG&gt;
    scriptSig:    &lt;0 &lt;32-byte-hash&gt;&gt;
                  (0x220020{32-byte-hash})
    scriptPubKey: HASH160 &lt;20-byte-hash&gt; EQUAL
                  (0xA914{20-byte-hash}87)
 (quoted from BIP-141).

In principle one could put witness and scriptSig (with "OP_FALSE" in
places of the signatures) in the raw transaction and make inputscript
always the scriptPubKey of the corresponding output.  Then one also
doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
nested in bip16 p2sh" transactions.

Regards,
  Jochen


</pre>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">_______________________________________________
bitcoin-dev mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------025D8A9ED594D5FDC3F544C7--

--iN0N0tFHgqOJln4tDXdFvgUfN4jRkpMhO--

--P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXs675AAoJED6nkklm0EibrtMP/RxUkbi2WBSFrYJwyA26tSjI
zpLw+W6Op8pmLYQXOA7DTqN07biCFKRCHNKdm+SXkTS108eisDkYdYEtbpz4GpG0
f/qUy1PKigyvuJFzI0BKK/SCpWeafeDM9ISjYbDiaODO/SkiLbAuRbyS9hj9NQpe
eljNZopggLddFUnvAqldjq9CryeoQeXqaD3JlIViZ4V+j49qopgzvjitB3Dbpk9N
rjes3xAj6oStIzZF9PVnJefkt1KG8VlG+pyDZya+0s93xAHsKYU9968ikLQ9U0/B
U68zjo7I6fHK0Qt+eiiR7WOqjol9j9dJfrDatiDsvqmxiSYo81y+8Txzk+JOX7Zb
6xusz0BHDQtJZnGBC5iLHVzapug5TxDxR6mc7om2188p4j9I0iWVst/93OGcIogI
LY9z8OP20b/Tx/0PIhJPj8tTWBqTJt07P4nsnMgOzkUOUC5t6Kn+QM+QN74PSCHX
VRFBAHHkQUsN5p1mmAGZcYydAkinLZ0NbEObFuTKYdehZXKdVxuaiPRaFMrrhEBR
6yfS4lTUFPPKXKPiAZlsiwj/PhCRduBcx1bggY71+c7FUGzOz0POPMyhXqCLFO9R
k21LTiKPyK4iV0M2vTwwtpSFx+X3ua1oDS98QTZZdc1os0kRLtP+RUlx8UWAGvaa
QRK643UrxGBb/vP8RPz+
=TGSI
-----END PGP SIGNATURE-----

--P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N--