To: "Dana L. Coe" <dana.coe@bitlox.com>,
	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>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57B44BCB.3010400@jonasschnelli.ch>
Date: Wed, 17 Aug 2016 13:34:35 +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: <D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="wCTk9xjvjKcSEAeABAlPkp2GdRVfKSC6n"
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wCTk9xjvjKcSEAeABAlPkp2GdRVfKSC6n
Content-Type: multipart/mixed; boundary="UHQ17xuDfiuDle6Gx1dd8SBc4tqjpSBPN"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: "Dana L. Coe" <dana.coe@bitlox.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <57B44BCB.3010400@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>
In-Reply-To: <D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>

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

Hi Dana

>> The URI scheme does not require any sorts of wallet app level
>> configuration (where the stdio/pipe approach would require to configur=
e
>> some details about the used hardware wallet).
>=20
> Hi everybody, just thought I=92d throw my opinion in here.
>=20
> The URI scheme is a nice idea, but this ignores the fact that hardware =
wallet vendors do most of the work on talking between the computer/mobile=
 and the wallet on a lower level of communication. In the case of BitLox,=
 the base protocol is Google=92s ProtoBuf. The commands and transaction d=
ata is in a =93schema=94 which is then encoded in different methods acces=
sible via ProtoBuf (depending on the data being sent). The advantages of =
this protocol is that it can be implemented on a wide variety of platform=
s. (but that=92s a whole 'nother discussion)
>=20
> The URI would be handled waaaaay up in the specific application (such a=
s the mytrezor wallet software or the various standalone wallets) - nowhe=
re near the actual hardware communications layer.

This is maybe a question of the scope.
The BIP I'm proposing would make a clear interface cut between
wallet-with-unsigned-transaction and a signing-device (and maybe between
wallet-requires-pubkey, signing-device generate some pubkeys [or
non-hardened xpub]).

The detached-signing proposal does not duplicate work. It just moves the
current plugin design into a separate application. Plugins in security
and privacy critical wallet software is something that should probably
be avoided.

It's intentional at a high level to allow maximum flexibility at the
hardware interaction layer.

Your protobuf example is a good use-case. You could implement your
custom processes behind the URI scheme (which is probably way more
efficient then writing a couple of wallet plugins where you =96 at the en=
d
=96 mostly don't control the deployment and the source-code).

Defining a standard on the hardware interaction layer is possible, but a
fairly different approach.

</jonas>


--UHQ17xuDfiuDle6Gx1dd8SBc4tqjpSBPN--

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

iQIcBAEBCAAGBQJXtEvMAAoJECnUvLZBb1Ps3vIP/2ymnr6yvM5NSx9TH0Sk74ft
46tPgFYsIoXo+onvhQ4bW6mx3SYbGrieBe47dLPwbrnaxU6lfEtys54IiVSBurFF
U6zzTVSui66DNkBbPtvRkl1uIN1fNODUtcPgfjWAkibA7nws8Dx+FB+yM6asb4gf
81g/HSm3hXsflaUftm0cQ2IiA4CAlkEvuT0IU/bf2PGkT1FouROvUcrBQxpsIyB+
JnL2yIBfoDBQ6/WAx3wuvGrbgHCREWsyTxBesLv9MzeljYxSPrdfn1QHzZSLx9rW
3VpriKNWoNbbwa1epS9f20fFkz6RuPHkaqzEX9wMCfWIga+LqD45L+VFPdv4mhwE
J6VDHvZrsw86ykb5XnMAAoKSFfI9QFZyxeTU6aXNArIFfQhw59xNEVgxP+mQpMBz
cLa26tr1zI9keG69hbTnnhzc5ETLKmJXg12Wosu4NZXA2qu8KszYp174UAOFlCSg
eZEemIAPrG6KNWVFl2uTUIcZwpO6wV5VNf5aX7+fRrt7dZEus1RyTRWFycgMRFih
TieYXWSJ+1H0oCXBAeZDNGTCqnd1EqtEsM2hqnJYz+HBZzCme44mNc367d0PVNz3
HaBvnVzBhtUJr5wM6cs2E0IG5DJYz02wFBVoSZ9iv9vA5lZRokdtevdUapxHITGc
T5pvf3OJ4LGNSHqGlZYh
=x2IO
-----END PGP SIGNATURE-----

--wCTk9xjvjKcSEAeABAlPkp2GdRVfKSC6n--