path: root/e5/e87b5a5b9dab2a65cf63dfed53d83a80ee2f53

Return-Path: <marek@palatinus.cz>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E47A98B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 18 Aug 2016 09:15:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0B11A1C9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 18 Aug 2016 09:15:54 +0000 (UTC)
Received: by mail-wm0-f52.google.com with SMTP id i5so22710259wmg.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 18 Aug 2016 02:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=palatinus-cz.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=NnDLEkotJrF7J0zZ8j4pKoypMk9Azzj2bfvOMp5hpok=;
	b=UWYFbufLkYszrcvhDhNFNcfhQPw8Ykq6coIBQ9QHS90lh5ggnD+sn4nVDGhxANm5S9
	LkizElAw/1pj6rYWrGRQf17RrH9N4ei/F6yXF5RbTdJCoXlqfimHbonCvQrnz5VWTjFB
	1HHGFc9/qVw7ufbiLQ7wGbfKgH3zCBkJZYdapVspbWuHbatr8WOg5QmKJarGQIMWU039
	YHG3Vw5sgQFgJC9YF4hjqEY8CaXpxAUvyStXNZIGMWq+jSBtTjOdLhXyFZCDcEuVNwub
	eHcigA3p+v2qqS9MaG3oAiLG5orYVqS0w1Z/qEcLeJAXup1zlKlUKT0yZGxaRoKm6041
	beBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=NnDLEkotJrF7J0zZ8j4pKoypMk9Azzj2bfvOMp5hpok=;
	b=MMRmXO4AGS+3WM2mC8jEIPonaDz5N4QX8NZP5atS7/UkMsC8i+axEFICjUQiL9qCHN
	3524dex++nd1dvyYJKPtcqcM45Sdwl8YJbpq9yRdCo/ov3LreiMVyRA/bxjTVr+vLFTV
	gnZPVTpgGJa63HrPg9NWKYKSSM2WxjU9DcTO/MSocRjjxdlU8/MSjp8BcN03MiX6K9VE
	aX3kev5eoqS5Jk0kjp5fIWX2xhr3jEheWGss5fml62ff+3M2oYwn3yfh49/4QnSBoQKT
	XtDId/pTPPFsXU5FF6mgiyV0Oppsk/DFJeqjpcONKWkcb3FHdREPaExDwQuy/OreRxwm
	J0Eg==
X-Gm-Message-State: AEkoouv8hQACzvjSlrwT9QaLb8Y8UM/TyuOy0tq+wgsHm3/t1G5KxOzVnfIsnVhKlWfPflK57j6NwkN6y3uNOA==
X-Received: by 10.28.199.199 with SMTP id x190mr3751142wmf.70.1471511753617;
	Thu, 18 Aug 2016 02:15:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.43.135 with HTTP; Thu, 18 Aug 2016 02:15:23 -0700 (PDT)
In-Reply-To: <57B55B8C.1070001@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>
From: Marek Palatinus <marek@palatinus.cz>
Date: Thu, 18 Aug 2016 11:15:23 +0200
Message-ID: <CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/alternative; boundary=94eb2c0d75145b99ef053a550736
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 09:15:56 -0000

--94eb2c0d75145b99ef053a550736
Content-Type: text/plain; charset=UTF-8

> Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?

The main benefit is that you don't need "standard" to solve problem, but
use natural tools in given environment and programming stack. Build a
"standard" on top of URI protocol is a huge limitation, which does not give
any advantage.

We already see issues with dead simple "bitcoin uri" standard, it barely
works in most of bitcoin apps. Think of vague definitions of parameters or
ability to send payment requests over it. HW API would be complicated by an
order of magnitude and I have serious concerns that it will be helpful for
anything. So why complicate things.

> How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?

Interprocess communication/libraries/dependencies on Android are not bound
to specific transport anyhow. Such library could be used by any android
app, and the library would implement proper transports for various
supported vendors. USB for Trezor, NFC for something different etc. If the
point is "make life of app developers easier", let's do this and do not
define artifical "standards".

slush


On Thu, Aug 18, 2016 at 8:54 AM, Jonas Schnelli <dev@jonasschnelli.ch>
wrote:

> 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.
>
> I think this is easily solvable. The required data to verify and sign a
> (standard) bitcoin transaction (including P2WSH multi-sig) is manageable.
>
> IMO what a signing devices requires in order to sign a (standard)
> transaction:
> -> serialized tx
> -> serialized tx of the inputs
> -> scriptPubKey of the inputs
> -> inputs redeem-Scripts
> -> input amounts
> -> position of the change output any maybe its keypath
> -> cosigners pubkeys for inputs and changeaddress
>
> This seems to be manageable for a 1 round communication?
> Or do I miss something?
>
>
> > 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.
>
> I think multiple rounds would still be possible with a clever design.
> Although I could imaging that >95% of the users transaction would
> require only a single "shot".
>
> Whats the benefits of the multiple rounds communication? Would a single
> round result in to many data transported?
>
> Passing a 300kb chunk (assuming a large transaction) over a URI scheme
> requires a couple of milliseconds on standard Smartphones or PCs.
>
> > 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).
>
> The URI-based API allows transmitting data of multiple megabytes while
> there is no need for...
> * dependencies of any form (library, etc.)
> * library support for a particular language
> * platform that supports the dependencies of the library (like USBHID,
> not supported by iOS)
>
> Can you elaborate what benefits you would get from the library approach
> and how the library API would be different form the proposed URI-scheme?
>
> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
>
> Thanks
> --
> </jonas>
>
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">Can you elabora=
te what benefits you would get from the library approach</span><br style=3D=
"font-size:12.8px"><span style=3D"font-size:12.8px">and how the library API=
 would be different form the proposed URI-scheme?</span><div><span style=3D=
"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">T=
he main benefit is that you don&#39;t need &quot;standard&quot; to solve pr=
oblem, but use natural tools in given environment and programming stack. Bu=
ild a &quot;standard&quot; on top of URI protocol is a huge limitation, whi=
ch does not give any advantage.</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">We already se=
e issues with dead simple &quot;bitcoin uri&quot; standard, it barely works=
 in most of bitcoin apps. Think of vague definitions of parameters or abili=
ty to send payment requests over it. HW API would be complicated by an orde=
r of magnitude and I have serious concerns that it will be helpful for anyt=
hing. So why complicate things.</span></div><div><span style=3D"font-size:1=
2.8px"><br></span></div><div><span style=3D"font-size:12.8px">&gt; How woul=
d the library approach work on mobile platforms? Would USB be</span><br sty=
le=3D"font-size:12.8px"><span style=3D"font-size:12.8px">the only supported=
 hardware communication layer?</span><span style=3D"font-size:12.8px"><br><=
/span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">Interprocess communication/libraries/dependen=
cies on Android are not bound to specific transport anyhow. Such library co=
uld be used by any android app, and the library would implement proper tran=
sports for various supported vendors. USB for Trezor, NFC for something dif=
ferent etc. If the point is &quot;make life of app developers easier&quot;,=
 let&#39;s do this and do not define artifical &quot;standards&quot;.</span=
></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span st=
yle=3D"font-size:12.8px">slush</span></div><div><span style=3D"font-size:12=
.8px"><br></span></div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Thu, Aug 18, 2016 at 8:54 AM, Jonas Schnelli <span dir=3D"lt=
r">&lt;<a href=3D"mailto:dev@jonasschnelli.ch" target=3D"_blank">dev@jonass=
chnelli.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<span class=3D""><br>
&gt; I fundamentally disagree with the concept of driving signing workflow =
by<br>
&gt; the wallet software. Wallet software does not know in advance all data=
<br>
&gt; necessary for the signer to do the job. As Jochen mentioned above,<br>
&gt; Segwit vs Non-segwit use cases are a good example, but there may be ma=
ny.<br>
<br>
</span>I think this is easily solvable. The required data to verify and sig=
n a<br>
(standard) bitcoin transaction (including P2WSH multi-sig) is manageable.<b=
r>
<br>
IMO what a signing devices requires in order to sign a (standard)<br>
transaction:<br>
-&gt; serialized tx<br>
-&gt; serialized tx of the inputs<br>
-&gt; scriptPubKey of the inputs<br>
-&gt; inputs redeem-Scripts<br>
-&gt; input amounts<br>
-&gt; position of the change output any maybe its keypath<br>
-&gt; cosigners pubkeys for inputs and changeaddress<br>
<br>
This seems to be manageable for a 1 round communication?<br>
Or do I miss something?<br>
<span class=3D""><br>
<br>
&gt; Currently the TREZOR protocol works like device is a server and wallet=
<br>
&gt; is a client calling methods on it. It&#39;s like: &quot;Sign this for =
me,<br>
&gt; please&quot;, &quot;Ok, give me this information&quot;, &quot;Here it =
is&quot;, &quot;Now I need this<br>
&gt; another piece&quot;.... &quot;There is the signature&quot;. Wallet doe=
s not know in<br>
&gt; advance what will go next, and it is for sake of simplicity. I&#39;m q=
uite<br>
&gt; happy with the protocol so far.<br>
<br>
</span>I think multiple rounds would still be possible with a clever design=
.<br>
Although I could imaging that &gt;95% of the users transaction would<br>
require only a single &quot;shot&quot;.<br>
<br>
Whats the benefits of the multiple rounds communication? Would a single<br>
round result in to many data transported?<br>
<br>
Passing a 300kb chunk (assuming a large transaction) over a URI scheme<br>
requires a couple of milliseconds on standard Smartphones or PCs.<br>
<span class=3D""><br>
&gt; Considering the difference in between current hardware, I really don&#=
39;t<br>
&gt; think it is possible to find any minimal URI-based API good enough for=
<br>
&gt; communicating with all vendors. What I see more likely is some 3rd par=
ty<br>
&gt; libraries (JS, C++, Python, ...) defining high-level API and<br>
&gt; implementing hardware-specific protocols and transports as plugins. Th=
at<br>
&gt; way vendors are not limited by strict standard and application<br>
&gt; developers and services can integrate wide range of hardware wallets<b=
r>
&gt; easily. However, this can be done already and we do not need any<br>
&gt; standardization process (yet).<br>
<br>
</span>The URI-based API allows transmitting data of multiple megabytes whi=
le<br>
there is no need for...<br>
* dependencies of any form (library, etc.)<br>
* library support for a particular language<br>
* platform that supports the dependencies of the library (like USBHID,<br>
not supported by iOS)<br>
<br>
Can you elaborate what benefits you would get from the library approach<br>
and how the library API would be different form the proposed URI-scheme?<br=
>
<br>
How would the library approach work on mobile platforms? Would USB be<br>
the only supported hardware communication layer?<br>
<br>
Thanks<br>
--<br>
&lt;/jonas&gt;<br>
<br>
</blockquote></div><br></div>

--94eb2c0d75145b99ef053a550736--