summaryrefslogtreecommitdiff
path: root/fd/43c7dcee44e51e50fa57b9095b6bbbccd7b46a
blob: b13aa351c9d2e4bac8a54513dc4e235cd8b288db (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
Return-Path: <hoenicke@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 597EC89F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Aug 2016 17:48:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C5C4415F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Aug 2016 17:48:54 +0000 (UTC)
Received: by mail-wm0-f49.google.com with SMTP id o80so184010702wme.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Aug 2016 10:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to; bh=MaqJ+s7vwdIzjtCY7pRbZgMo4nlwCE+HomDfjRYlxF8=;
	b=syr0SEZv7m7hcArPQUXglJUSVdtKSkoIab0KDChRrRHmHzTuotrcK4Q+DTLguiJxH4
	iFBIrFpzjwuA9cMhhnppznIm9wtx8OjgxFUW96jP04TzLNTicKnkTpvGaaKrdT1piJCr
	eikS/1py+bQKxMOB4g5vwNCKLZvvHniEovM1F5RWB+ECLD3AUwORhZcMTA6jBKG2Udsv
	bS4F0VDyqKgYjnHKkaoyR8pNmMMwGOQvmufy6wNmMhSahCHbc909wvMeWwX3LElBm0pp
	7rHNbIJah+vyBFtgnUQvOd/UK8FyY6ZJMLXezrvo2qwVz9gGQ5j11RIUavRmK5BplJWf
	mdCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to;
	bh=MaqJ+s7vwdIzjtCY7pRbZgMo4nlwCE+HomDfjRYlxF8=;
	b=NBZUgshxoyd2Zhby0nnVLUBwqg0cxSTMuDa3/mKpyKhPZ+P4YhbWH3FZZvibm5zc6b
	71CesLVaj4UVh8TOpD05Ak8d2DfO2xgJUZM1e5hFv7hWO2H7PwYF6Cv19e9Q8UEPhu/3
	p37AcNG4Iyln53lYAW5UjLr3zHUu5hFgHV2VZM8bKErl6PkDhP2//L3fcdQALgQLzM22
	d3xO9GDfRgQjEBC6rgVQX0/4mAlPUC5pRa/bNxokhxoRj65oxwAsEphsUUi0+sa9b0we
	mv/5mgLJV+FupgKFEYuAQnVMV+MSNISKlt1PA3bw1JW+4jo95qJ5uh7YIDTiiLo2ppvF
	e74w==
X-Gm-Message-State: AEkoouuS+mkGBioiF3re4IAW/sn3s3oOuWOyHjRmZcwKVMjYmqtp5RiuU4S28ncT2FYWyw==
X-Received: by 10.28.227.11 with SMTP id a11mr23091943wmh.29.1471369733066;
	Tue, 16 Aug 2016 10:48:53 -0700 (PDT)
Received: from [10.126.44.83] (ufr-132-230-194-97.eduroam-nat.uni-freiburg.de.
	[132.230.194.97]) by smtp.googlemail.com with ESMTPSA id
	17sm22777822wmf.6.2016.08.16.10.48.51
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 16 Aug 2016 10:48:51 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <57B31EBC.1030806@jonasschnelli.ch>
From: Jochen Hoenicke <hoenicke@gmail.com>
Message-ID: <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
Date: Tue, 16 Aug 2016 19:48:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <57B31EBC.1030806@jonasschnelli.ch>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="2fi8orpiGPtbrw8MwaLnOmBxLRpn7uxf7"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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: Tue, 16 Aug 2016 17:48:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2fi8orpiGPtbrw8MwaLnOmBxLRpn7uxf7
Content-Type: multipart/mixed; boundary="8wgLWc0SwTfTDeGDWsWVqjewInQutjpFU"
From: Jochen Hoenicke <hoenicke@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
References: <57B31EBC.1030806@jonasschnelli.ch>
In-Reply-To: <57B31EBC.1030806@jonasschnelli.ch>

--8wgLWc0SwTfTDeGDWsWVqjewInQutjpFU
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 <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



--8wgLWc0SwTfTDeGDWsWVqjewInQutjpFU--

--2fi8orpiGPtbrw8MwaLnOmBxLRpn7uxf7
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

iF4EAREIAAYFAlezUgMACgkQ6xfGteURk/VjqgEAiPz/i3THz68bm47vWjYKUHJj
kEicdh6U2tO1t30JsxkA/3X74rvUGxZkMT7o7TDrCUjgF99eiXRaDJjbIqEj56CE
=EkPF
-----END PGP SIGNATURE-----

--2fi8orpiGPtbrw8MwaLnOmBxLRpn7uxf7--