From: Jonas Schnelli <dev@jonasschnelli•ch>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Date: Wed, 17 Aug 2016 09:24:46 +0200 [thread overview]
Message-ID: <57B4113E.4010502@jonasschnelli.ch> (raw)
In-Reply-To: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
[-- Attachment #1.1: Type: text/plain, Size: 4003 bytes --]
Hi all
Thanks for the response.
Jochen's points:
===============
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:
=============
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 level.
URI scheme instead of stdio/pipe
--------------------------------
The URI scheme is not ugly. Its a modern way – implemented in almost all
platforms – 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:
===================
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:
===========
* 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/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
[2] https://developer.android.com/training/basics/intents/sending.html
</jonas>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-08-17 7:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-16 14:10 Jonas Schnelli
2016-08-16 14:48 ` Pavol Rusnak
2016-08-16 15:13 ` Jonas Schnelli
2016-08-16 15:21 ` Pavol Rusnak
2016-08-16 17:48 ` Jochen Hoenicke
2016-08-17 0:25 ` Thomas Kerin
2016-08-17 7:24 ` Jonas Schnelli [this message]
2016-08-17 7:40 ` Nicolas Bacca
2016-08-17 10:13 ` Dana L. Coe
2016-08-17 11:34 ` Jonas Schnelli
2016-08-17 17:06 ` Marek Palatinus
2016-08-18 6:54 ` Jonas Schnelli
2016-08-18 9:15 ` Marek Palatinus
2016-08-18 9:35 ` Jonas Schnelli
2016-08-18 9:43 ` Marek Palatinus
2016-08-18 9:49 ` Jonas Schnelli
2016-08-18 10:23 ` Nicolas Bacca
2016-08-24 10:31 ` Thomas Kerin
2016-08-16 19:22 ` Luke Dashjr
2016-08-17 0:03 ` Thomas Daede
2016-08-16 23:36 ` Aiqin Li
2016-08-17 0:14 ` Peter Todd
2016-08-17 7:27 ` Nicolas Bacca
2016-08-17 18:36 ` Bryan Bishop
2016-08-22 16:50 ` Moral Agent
2016-08-28 23:14 ` Corey Haddad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57B4113E.4010502@jonasschnelli.ch \
--to=dev@jonasschnelli$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox