public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Marek Palatinus <marek@palatinus.cz>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Date: Wed, 17 Aug 2016 19:06:08 +0200	[thread overview]
Message-ID: <CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com> (raw)
In-Reply-To: <57B44BCB.3010400@jonasschnelli.ch>

[-- Attachment #1: Type: text/plain, Size: 3709 bytes --]

Hi,

I fundamentally disagree with the concept of driving signing workflow by
the wallet software. Wallet software does not know in advance all data
necessary for the signer to do the job. As Jochen mentioned above, Segwit
vs Non-segwit use cases are a good example, but there may be many.

Currently the TREZOR protocol works like device is a server and wallet is a
client calling methods on it. It's like: "Sign this for me, please", "Ok,
give me this information", "Here it is", "Now I need this another
piece".... "There is the signature". Wallet does not know in advance what
will go next, and it is for sake of simplicity. I'm quite happy with the
protocol so far.

Considering the difference in between current hardware, I really don't
think it is possible to find any minimal URI-based API good enough for
communicating with all vendors. What I see more likely is some 3rd party
libraries (JS, C++, Python, ...) defining high-level API and implementing
hardware-specific protocols and transports as plugins. That way vendors are
not limited by strict standard and application developers and services can
integrate wide range of hardware wallets easily. However, this can be done
already and we do not need any standardization process (yet).

slush

On Wed, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Dana
>
> >> 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).
> >
> > Hi everybody, just thought I’d throw my opinion in here.
> >
> > 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’s ProtoBuf. The commands and transaction data
> is in a “schema” which is then encoded in different methods accessible via
> ProtoBuf (depending on the data being sent). The advantages of this
> protocol is that it can be implemented on a wide variety of platforms. (but
> that’s a whole 'nother discussion)
> >
> > The URI would be handled waaaaay up in the specific application (such as
> the mytrezor wallet software or the various standalone wallets) - nowhere
> 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 – at the end
> – 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>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4541 bytes --]

  reply	other threads:[~2016-08-17 17:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 14:10 [bitcoin-dev] Hardware Wallet Standard 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
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 [this message]
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=CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com \
    --to=marek@palatinus.cz \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dev@jonasschnelli.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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