To: bitcoin-dev@lists.linuxfoundation.org
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57B4113E.4010502@jonasschnelli.ch>
Date: Wed, 17 Aug 2016 09:24:46 +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: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="kgjDfHt6cCgkSlCPBOuMQQKs6oWncoWmM"
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--kgjDfHt6cCgkSlCPBOuMQQKs6oWncoWmM
Content-Type: multipart/mixed; boundary="f46BEp7VrMLum9wsfjMna9nRIsPji9qGR"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <57B4113E.4010502@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>
In-Reply-To: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>

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

Hi all

Thanks for the response.


Jochen's points:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Indeed. There are some missing points and I'd like to work this into the
BIP. Thanks for bringing this up.

Along with a support for wallet-creation with a xpub from the signing
device, we might also want to support loading multiple pubkeys into a
keypool from the device (in case someone likes to use hardened
derivation at all levels). I guess this would not be over-complex to
achieve.

Luke's points:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

USB / Plugin/Driver problematic
-------------------------------
I don't think it would be wise to set Trezors USB communication
(hardware interface) as "the standard". A) A USB stack/interaction in
wallets should be avoided IMO. B) This approach won't work for some
platforms (like iOS) due to technical and legal restrictions.

In my opinion, each hardware wallet has to provide custom software in
any case. We don't want to standardize how a hardware wallet has to do
backups, recovers, firmware upgrade, etc. and if we agree on that, then
hardware wallets must provide an application (mostly Chrome extensions
today) to implement theses processes.

Also diversity at the hardware interface will reduce centralized risks
for weak security/vulnerabilities.

The proposed URI scheme approach does not require any sorts of
libraries/dependencies. USB HID can be a problem for cross platform
desktop wallets as well as it won't work of one of the major mobile
platform (iOS). USB HID interaction can be restricted or disabled in non
superuser setups where I'm not aware of any restriction on URI-Scheme lev=
el.

URI scheme instead of stdio/pipe
--------------------------------
The URI scheme is not ugly. Its a modern way =96 implemented in almost al=
l
platforms =96 how applications can interact with each other while not
directly knowing each other. Registering a URI scheme like "bitcoin://"
has some concrete advantages over just piping through stdio.

Also, the stdio/piping approach does not work for mobile platforms
(where the URI scheme works).

The URI scheme does not require any sorts of wallet app level
configuration (where the stdio/pipe approach would require to configure
some details about the used hardware wallet).


Thomase D.'s points:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Standardizing to many layers of the interaction stack (including the
hardware interaction) will very likely result in vendors not sticking to
the standard.

I agree, the URI scheme has some fragility, but at a level where we can
handle it and with the advantage of abstracting the used brand/device
for privacy and security reasons.

> The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets.

Most operating systems allow to check if a certain URL-Scheme is
supported (registered), this would allow at least to check for known
major vendors (like trezor, etc.) which should solve most
multi-hardware-wallet use-cases.

The URI return scheme does work fine and with the correct set timeouts
it should result in a neat user experience.
It's the proposed way of application intercommunication in Apple iOS [1]
and Google Android [2].

Conclusion:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* Non of the points convinced me that there is a better alternative to
the proposed URI scheme interaction (please tell me if I'm stubborn).
* Also, we should move the end users UX in the center of the
problems-to-solve (and not overweight the ideal
code-/API-/hardware-interaction-design while ignoring the end user
experience).
* We should try to not over-standardize the interaction with the device
itself to allow flexibility on the hardware wallet vendor side.

[1]
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/i=
PhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.htm=
l
[2] https://developer.android.com/training/basics/intents/sending.html

</jonas>


--f46BEp7VrMLum9wsfjMna9nRIsPji9qGR--

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

iQIcBAEBCAAGBQJXtBE/AAoJECnUvLZBb1PsE6AP/R436hVU1/aeW067gC5D+0X2
OLtFAuXSoM2jFqqmPiREMl1H3MEvg5MS7t/G1ODBZF1oMdJwaKXDiGUj0707ZH7d
h0oSwbwqKdBA71gY0FHS4dQTYwBWJu9uQVRZ4ewRqxS4rvfMvLx+Zw/Z6IvGNYsU
UVqq37g2Wq2K78zEBApr26jeRCARWb5YwhFdiAgxJmreU9zfma6VWNoF8bmVK56P
u9CVku1KtfjzK7Wd8c8EEjANSQtU3Cexy3erimRUFRvmfl9yG7h+eZpYX3d3geiH
o0U7ZdAwJbSVnxKZDzQMT75v4fyQ58iKw5aSA63VNiszs7P9MVF+qxqt2TCp6sya
r1stDm1/icshs1fT/NH/mpUYf9tDIe0VN/ORFu4dB1kjDb2WtxofEXkMyVNwA1BO
bWd7sATIMVY2Qnor1NEs28PryHM1Yp3KfiEcEW7m9Yt1rRDrHhc2YoHvFoaw8nxz
9KkIvNovkJl3jy7cpHicLBVMF83D7pWnQao8J+LDamnws+8XeywRi+EBlMFGSKAX
9l41cmpdgEBSHrxzQ3Hcg/TiX1lIWXkrfwDjoUcSZHPSK55YCbe5MPubNRFfEUWG
Q1nyyiK21AUlZhquNaLZDPcItcvxiQNZxoDDXwhG8FBNpLElxBJZQtcwyPBCK/eC
gYzXY1An+ZorUwV7X7QF
=YvJB
-----END PGP SIGNATURE-----

--kgjDfHt6cCgkSlCPBOuMQQKs6oWncoWmM--