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
|
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 78152722
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 06:54:11 +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 A12F6FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 06:54:10 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 3B4CB2E60612; Thu, 18 Aug 2016 08:54:09 +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 4360B2D002F0;
Thu, 18 Aug 2016 08:54:08 +0200 (CEST)
To: Marek Palatinus <marek@palatinus.cz>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57B55B8C.1070001@jonasschnelli.ch>
Date: Thu, 18 Aug 2016 08:54:04 +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-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="R3R3V1VGKSW1va958tCjgJ5M7B1RSKcBN"
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 06:54:11 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--R3R3V1VGKSW1va958tCjgJ5M7B1RSKcBN
Content-Type: multipart/mixed; boundary="2ITnGAPKidLdBXMwLvIiMdUFOGoPXVvOL"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: Marek Palatinus <marek@palatinus.cz>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <57B55B8C.1070001@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>
In-Reply-To: <CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
--2ITnGAPKidLdBXMwLvIiMdUFOGoPXVvOL
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi
> I fundamentally disagree with the concept of driving signing workflow b=
y
> the wallet software. Wallet software does not know in advance all data
> necessary for the signer to do the job. As Jochen mentioned above,
> Segwit vs Non-segwit use cases are a good example, but there may be man=
y.
I think this is easily solvable. The required data to verify and sign a
(standard) bitcoin transaction (including P2WSH multi-sig) is manageable.=
IMO what a signing devices requires in order to sign a (standard)
transaction:
-> serialized tx
-> serialized tx of the inputs
-> scriptPubKey of the inputs
-> inputs redeem-Scripts
-> input amounts
-> position of the change output any maybe its keypath
-> cosigners pubkeys for inputs and changeaddress
This seems to be manageable for a 1 round communication?
Or do I miss something?
> Currently the TREZOR protocol works like device is a server and wallet
> is a client calling methods on it. It's like: "Sign this for me,
> please", "Ok, give me this information", "Here it is", "Now I need this=
> another piece".... "There is the signature". Wallet does not know in
> advance what will go next, and it is for sake of simplicity. I'm quite
> happy with the protocol so far.
I think multiple rounds would still be possible with a clever design.
Although I could imaging that >95% of the users transaction would
require only a single "shot".
Whats the benefits of the multiple rounds communication? Would a single
round result in to many data transported?
Passing a 300kb chunk (assuming a large transaction) over a URI scheme
requires a couple of milliseconds on standard Smartphones or PCs.
> Considering the difference in between current hardware, I really don't
> think it is possible to find any minimal URI-based API good enough for
> communicating with all vendors. What I see more likely is some 3rd part=
y
> libraries (JS, C++, Python, ...) defining high-level API and
> implementing hardware-specific protocols and transports as plugins. Tha=
t
> way vendors are not limited by strict standard and application
> developers and services can integrate wide range of hardware wallets
> easily. However, this can be done already and we do not need any
> standardization process (yet).
The URI-based API allows transmitting data of multiple megabytes while
there is no need for...
* dependencies of any form (library, etc.)
* library support for a particular language
* platform that supports the dependencies of the library (like USBHID,
not supported by iOS)
Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?
How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?
Thanks
--
</jonas>
--2ITnGAPKidLdBXMwLvIiMdUFOGoPXVvOL--
--R3R3V1VGKSW1va958tCjgJ5M7B1RSKcBN
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
iQIcBAEBCAAGBQJXtVuNAAoJECnUvLZBb1PsXEcP/icfr/0JDXgxL/KoXYUPSHxf
5RyeNRRF6QcD90nic/D1J6v8xxdKE99UINo8Ww2nMO16qcWxd5hL7vC12s0L0zWY
oz292dyDhFoWREUrCgrtSKt9TULi4foWMgw9kLoX6UMkjjK4QOQ7e+/EAtuNQxku
rnIqNw8bLA1lllCttEAvdhXC34apuZQJA3vR+RdssYYP+vAQCvGB7n+AXSk+YOYG
saAOt5CVVUao8J0CHf3ysqtImsZHPhUnoJeJOQ4ZbWQENNi680CrYNrp0QAKjCSy
5zRiaKe80pd1s6cexmgD6VKnBO1vNGEVWW7xn5tPFTCODr9g4x+d/sB3bCvHIAaQ
+lSWdGNFunygKEUDZQ5LgR3MBkXffu6usJ6FlZzFDiNVOmkH6RM9oIo34Xjf7rMe
2FjaBYcKajtO6OvD1jm5f5O+ZiY5aESC8FCAC+Wp1bTBeqQ1uGa0hpKuq3Ukb0KC
zZPhmRqUxOv3D6JI/iXxyyoTx3MsrdgM5zsh68+au1hJwSLTGigBDIGFOVCUduLu
ExxweD4GBTa4IxzahYdaA1ub8g7baF6Op9JK21k4o6Rn30S2YJU6pXQBa/cX5NWm
qxdZTvywBgaEvuoLA7x2ArD1yCdVI5P50ZGyc3c72Wuy/bUhgTNI53mHig2814La
QzyccLNBP/GHuSJHfCue
=z78C
-----END PGP SIGNATURE-----
--R3R3V1VGKSW1va958tCjgJ5M7B1RSKcBN--
|
