To: bitcoin-dev@lists.linuxfoundation.org
References: <57B31EBC.1030806@jonasschnelli.ch>
	<201608161922.30588.luke@dashjr.org>
From: Thomas Daede <bztdlinux@gmail.com>
Message-ID: <3a183d3a-757c-ec32-0bd1-c3f8a1982edd@gmail.com>
Date: Tue, 16 Aug 2016 17:03:00 -0700
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: <201608161922.30588.luke@dashjr.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Precedence: list

On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:
> It would be best if the hardware protocol were standardised, so the user 
> doesn't need a plugin of *any* sort... I notice some hardware wallets have 
> begun to implement (or reuse) Trezor's interface, so that would seem a good 
> place to start?

I also agree with this - the user experience would be a lot better
without the need to install custom adapter software, especially for the
desktop case.

There could be two layers to the specification - the raw messages that
need to be passed, and the transport mechanism to pass them (USB HID, QR
code, audio...). For the most common case (USB), both layers could be
defined, and other transports could be added later. This split already
exists in the draft specification, though it's not very clear (URIs
include return URIs that don't make sense for a pipe, for example).

The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets. This means that the "driver" would have to include a GUI to
select this. Also, passing return URIs seems rather fragile - are there
any other examples of protocols that use URIs for bidirectional IPC?

Thomas