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
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0F9CF8D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 09:35:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2155917D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 09:35:11 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 384A52E60612; Thu, 18 Aug 2016 11:35:10 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro-2.local (84-73-208-41.dclient.hispeed.ch
[84.73.208.41]) by server3 (Postfix) with ESMTPSA id 6FC882E602B5;
Thu, 18 Aug 2016 11:35:09 +0200 (CEST)
To: Marek Palatinus <marek@palatinus.cz>
References: <57B31EBC.1030806@jonasschnelli.ch>
<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
<57B4113E.4010502@jonasschnelli.ch>
<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
<57B44BCB.3010400@jonasschnelli.ch>
<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
<57B55B8C.1070001@jonasschnelli.ch>
<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57B58149.8000200@jonasschnelli.ch>
Date: Thu, 18 Aug 2016 11:35:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="aIFP06AHJ8bDO3O6u4KKdcHSqGIEOxwqH"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Thu, 18 Aug 2016 09:35:12 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aIFP06AHJ8bDO3O6u4KKdcHSqGIEOxwqH
Content-Type: multipart/mixed; boundary="VOkqjpmmhQxpCCSKdwJWq8rQT8hcgfPL3"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: Marek Palatinus <marek@palatinus.cz>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <57B58149.8000200@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
References: <57B31EBC.1030806@jonasschnelli.ch>
<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
<57B4113E.4010502@jonasschnelli.ch>
<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
<57B44BCB.3010400@jonasschnelli.ch>
<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
<57B55B8C.1070001@jonasschnelli.ch>
<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
In-Reply-To: <CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
--VOkqjpmmhQxpCCSKdwJWq8rQT8hcgfPL3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi
> The main benefit is that you don't need "standard" to solve problem, bu=
t
> use natural tools in given environment and programming stack. Build a
> "standard" on top of URI protocol is a huge limitation, which does not
> give any advantage.
Standards can help an ecosystem to grow, can help to sustain a good user
experience.
The hardware wallet vendors have used "natural tools" and look where we
are. We have *native* plugins in Electrum, Copay, etc. for different
hardware wallets. Mostly the plugins are in the code base of the wallet,
which makes it =E2=80=93 in theory =E2=80=93 impossible to change from th=
e perspective
of the hardware wallet vendor (there is no control of the deployment if
there are bugs in the plugins code).
The plugins functions overlap significant.
I think this is a bad design for security critical applications.
What I want as hardware wallet user:
* I'd like to have a trusted application (layer) where I'm sure I'm
using software provided through my hardware wallet vendor.
What I want as hardware wallet vendor:
* I'd like to be able to provide and update a software layer (app) to my
customer with the ability to provide code signatures and security
updates anytime. I do want to control the user experience.
> We already see issues with dead simple "bitcoin uri" standard, it barel=
y
> works in most of bitcoin apps. Think of vague definitions of parameters=
> or ability to send payment requests over it. HW API would be complicate=
d
> by an order of magnitude and I have serious concerns that it will be
> helpful for anything. So why complicate things.
As far as I know most bitcoin wallets do support the bitcoin:// URI
scheme quite well.
I agree that BIP70 is a mess (including the bitcoin:// additions).
The proposed URI scheme would be completely different. The only
similarity is using the URI scheme as transport layer (which is the
proposed long term inter-app communication layer by Apple and Google).
>> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
>=20
> Interprocess communication/libraries/dependencies on Android are not
> bound to specific transport anyhow. Such library could be used by any
> android app, and the library would implement proper transports for
> various supported vendors. USB for Trezor, NFC for something different
> etc. If the point is "make life of app developers easier", let's do thi=
s
> and do not define artifical "standards".
So you propose having one library that would support multiple vendors?
What if new vendors add a new transport layer (lets assume NFC or
Bluetooth), wouldn't that result in every possible consumer of that
library (all wallets) need to update before the new vendors transport
layer could be used, resulting in a huge deployment process probably
require many month until it can be used?
What if there is a critical security issue in the library? How would the
deployment plan looks like?
I really think we should remove the "hardware communication layer" from
wallets and move it towards the hardware vendor app.
What about iOS? Should we just leave that platform unsupported with
hardware wallets?
</jonas>
--VOkqjpmmhQxpCCSKdwJWq8rQT8hcgfPL3--
--aIFP06AHJ8bDO3O6u4KKdcHSqGIEOxwqH
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
iQIcBAEBCAAGBQJXtYFKAAoJECnUvLZBb1PseiMP/2sm2i0nG+1ta6OWUpFSmQp0
duQujm1LS/UxettEQYiu4IMzQ/IhDeNeG0ZYPghgK30x3sjsJKWvW3OejvVkZsMw
EYWhUbk2+nM7cnY5af1rLGHtiUT+HkHFVQhQKtqHSWjGVsKCbS8faIQC00GmlgfR
YcdpQPy8rXuTsyBfuicuYEF5HioL0MXmUxKTP2xxjbnk8ORE4q3DecnonASPl1Mi
hxDNZh/QuU/3UyOKe4L+GXGlhmaaVyAAN37I1+zyMCsn0HBq2WCDUHvERe7a5zxK
YG8G3lm00zLw0eHd4IACv4kg8Eg+se4NwBVKP2flnpKtMbcXuDKPCNf0FY0cvl6+
AxKJQsECqSoXdIBWdg7SUIFt+4kGK2edS+SD+YlSGbdn/J+hEXAVMR2S04tbmN89
0Ypv9+X7+amkdgli/fOpF4MMnbEiszfS8dY3uXqTAb7VwVAvqOf/9EmeZJdNVREI
Sy5eTPpZJx/pi4aVlLb19Ui+brMqRNGG7jDveiy3S1rpd0+QnxnqowPkJZG0X9Si
f0rKdtuF+KSpDBW9JNbpAwvsLM9J3s/e/hXvxik9ikOu+CMM23baxuoFYIsc4V+E
hk3jRqSyfmEVVrebZ5XJs6jGed7z3gCbDU2q7xhesEjtxGhjhXiQOIMlQob/Vzci
7D6jGBSRbo5VQyIBukZd
=rvuI
-----END PGP SIGNATURE-----
--aIFP06AHJ8bDO3O6u4KKdcHSqGIEOxwqH--
|
