Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B42878DC for ; Wed, 17 Aug 2016 07:24:53 +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 A8A40107 for ; Wed, 17 Aug 2016 07:24:52 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 9BEFD2E60606; Wed, 17 Aug 2016 09:24:51 +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 (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id BDEDB2D002F0 for ; Wed, 17 Aug 2016 09:24:50 +0200 (CEST) To: bitcoin-dev@lists.linuxfoundation.org References: <57B31EBC.1030806@jonasschnelli.ch> <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> From: Jonas Schnelli 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 07:24:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kgjDfHt6cCgkSlCPBOuMQQKs6oWncoWmM Content-Type: multipart/mixed; boundary="f46BEp7VrMLum9wsfjMna9nRIsPji9qGR" From: Jonas Schnelli To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <57B4113E.4010502@jonasschnelli.ch> Subject: Re: [bitcoin-dev] Hardware Wallet Standard References: <57B31EBC.1030806@jonasschnelli.ch> <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 --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--