MIME-Version: 1.0
In-Reply-To: <57B584BF.7000004@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>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
	<57B55B8C.1070001@jonasschnelli.ch>
	<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
	<57B58149.8000200@jonasschnelli.ch>
	<CAJna-Hj8HQy9Dhx3Gx8CpmpgoiQZ2waaj9o5b6hHwda4Dm_fGw@mail.gmail.com>
	<57B584BF.7000004@jonasschnelli.ch>
From: Nicolas Bacca <nicolas@ledger.fr>
Date: Thu, 18 Aug 2016 12:23:21 +0200
Message-ID: <CALGb225DLv22ktt_7HJTcuPphJ=TMEU_b3LApBJy17KgAZwSzQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1143e548ad3ac8053a55f888
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Precedence: list

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

On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi
>
> > I have some experience with hardware wallet development and its
> > integration and I know it's a mess. But it is too early to define such
> > rigid standards yet. Also, TREZOR concept (device as a server and the
> > primary source of workflow management) goes directly against your
> > proposal of wallet software as an workflow manager. So it is clear NACK
> > for me.
>
> The current question =E2=80=93 as already mentioned =E2=80=93 is we ACK t=
o work together
> on a signing protocol or if we NACK this before we even have started.
>

ACK for Ledger. What's necessary to sign a transaction is well known, I
don't see how driving any hardware wallet from the wallet itself or from a
third party daemon implementing that URL scheme would make any difference,
other than providing better devices interoperability, as well as easier
maintenance and update paths for the wallets.

--=20
Nicolas Bacca | CTO, Ledger

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev <span dir=3D"l=
tr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Hi<br>
<span class=3D""><br>
&gt; I have some experience with hardware wallet development and its<br>
&gt; integration and I know it&#39;s a mess. But it is too early to define =
such<br>
&gt; rigid standards yet. Also, TREZOR concept (device as a server and the<=
br>
&gt; primary source of workflow management) goes directly against your<br>
&gt; proposal of wallet software as an workflow manager. So it is clear NAC=
K<br>
&gt; for me.<br>
<br>
</span>The current question =E2=80=93 as already mentioned =E2=80=93 is we =
ACK to work together<br>
on a signing protocol or if we NACK this before we even have started.<br></=
blockquote><div><br></div><div>ACK for Ledger. What&#39;s necessary to sign=
 a transaction is well known, I don&#39;t see how driving any hardware wall=
et from the wallet itself or from a third party daemon implementing that UR=
L scheme would make any difference, other than providing better devices int=
eroperability, as well as easier maintenance and update paths for the walle=
ts.</div></div><div><br></div>-- <br><div class=3D"gmail_signature" data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">Nicolas =
Bacca | CTO, Ledger<div><br></div><div><br></div></div></div></div></div>
</div></div>

--001a1143e548ad3ac8053a55f888--