MIME-Version: 1.0
In-Reply-To: <57B44BCB.3010400@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
From: Marek Palatinus <marek@palatinus.cz>
Date: Wed, 17 Aug 2016 19:06:08 +0200
Message-ID: <CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e014934ac106188053a477dbf
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Precedence: list

--089e014934ac106188053a477dbf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 configur=
e
> >> some details about the used hardware wallet).
> >
> > Hi everybody, just thought I=E2=80=99d 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=E2=80=99s ProtoBuf. The commands and transact=
ion data
> is in a =E2=80=9Cschema=E2=80=9D which is then encoded in different metho=
ds 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. (b=
ut
> that=E2=80=99s a whole 'nother discussion)
> >
> > The URI would be handled waaaaay up in the specific application (such a=
s
> 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 =E2=80=93 at =
the end
> =E2=80=93 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
>
>

--089e014934ac106188053a477dbf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I fundamentally disagree with the c=
oncept 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. A=
s Jochen mentioned above, Segwit vs Non-segwit use cases are a good example=
, but there may be many.</div><div><br></div><div>Currently the TREZOR prot=
ocol works like device is a server and wallet is a client calling methods o=
n it. It&#39;s like: &quot;Sign this for me, please&quot;, &quot;Ok, give m=
e this information&quot;, &quot;Here it is&quot;, &quot;Now I need this ano=
ther piece&quot;.... &quot;There is the signature&quot;. Wallet does not kn=
ow in advance what will go next, and it is for sake of simplicity. I&#39;m =
quite happy with the protocol so far.</div><div><br></div><div>Considering =
the difference in between current hardware, I really don&#39;t think it is =
possible to find any minimal URI-based API good enough for communicating wi=
th all vendors. What I see more likely is some 3rd party libraries (JS, C++=
, Python, ...) defining high-level API and implementing hardware-specific p=
rotocols and transports as plugins. That way vendors are not limited by str=
ict standard and application developers and services can integrate wide ran=
ge of hardware wallets easily. However, this can be done already and we do =
not need any standardization process (yet).</div><div><br></div><div>slush<=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed=
, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">Hi Dana<br>
<span class=3D""><br>
&gt;&gt; The URI scheme does not require any sorts of wallet app level<br>
&gt;&gt; configuration (where the stdio/pipe approach would require to conf=
igure<br>
&gt;&gt; some details about the used hardware wallet).<br>
&gt;<br>
&gt; Hi everybody, just thought I=E2=80=99d throw my opinion in here.<br>
&gt;<br>
&gt; 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, th=
e base protocol is Google=E2=80=99s ProtoBuf. The commands and transaction =
data is in a =E2=80=9Cschema=E2=80=9D which is then encoded in different me=
thods accessible via ProtoBuf (depending on the data being sent). The advan=
tages of this protocol is that it can be implemented on a wide variety of p=
latforms. (but that=E2=80=99s a whole &#39;nother discussion)<br>
&gt;<br>
&gt; The URI would be handled waaaaay up in the specific application (such =
as the mytrezor wallet software or the various standalone wallets) - nowher=
e near the actual hardware communications layer.<br>
<br>
</span>This is maybe a question of the scope.<br>
The BIP I&#39;m proposing would make a clear interface cut between<br>
wallet-with-unsigned-<wbr>transaction and a signing-device (and maybe betwe=
en<br>
wallet-requires-pubkey, signing-device generate some pubkeys [or<br>
non-hardened xpub]).<br>
<br>
The detached-signing proposal does not duplicate work. It just moves the<br=
>
current plugin design into a separate application. Plugins in security<br>
and privacy critical wallet software is something that should probably<br>
be avoided.<br>
<br>
It&#39;s intentional at a high level to allow maximum flexibility at the<br=
>
hardware interaction layer.<br>
<br>
Your protobuf example is a good use-case. You could implement your<br>
custom processes behind the URI scheme (which is probably way more<br>
efficient then writing a couple of wallet plugins where you =E2=80=93 at th=
e end<br>
=E2=80=93 mostly don&#39;t control the deployment and the source-code).<br>
<br>
Defining a standard on the hardware interaction layer is possible, but a<br=
>
fairly different approach.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
&lt;/jonas&gt;<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--089e014934ac106188053a477dbf--