From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B5E558D7 for ; Wed, 17 Aug 2016 17:06:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F22625F for ; Wed, 17 Aug 2016 17:06:40 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id i5so245101570wmg.0 for ; Wed, 17 Aug 2016 10:06:40 -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=mgvnCfRNHgwyzK1J4Jkot8Wi7LMWRU0XU1CNmrYkuzY=; b=hJt8nHMnF9MjgkL2qMLH+AjZrJejmhmBD+lxhLkfx29krx3Brr+aJTqqB8S4Qt8yLx DvolmJgTDUadqVGC0Nryegh5EgXOdyuAfeMUPO/82VRJzFIhIQwwrXXt83JpNBYifkrQ KpgKOmqSvrz2wGRtcHgy9BK9MfmzwqAPZgeD4gIz2LCKC5uix9SCKiQkWUdvJthsXrCV sSzEc/ciImbgUEkUfIEm/U5h0S0mkiqegYN6B1mWXmXd7ByocgUuVwtyDiAOSlMOBcQ3 PnyGZtTTrkfIZBeAnNcDKun0mUkoaanMxtn2I6yrbnn8tEAn9R1PJA5X/KQkfjw60WML 0kdg== 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=mgvnCfRNHgwyzK1J4Jkot8Wi7LMWRU0XU1CNmrYkuzY=; b=kB6ct1NxiH9LEgZ+1kgSTiBP2yNEk5i3Uf0kVuCJzCxSt7U59NT6AR9J6AGdqWIIrh BqEyiwhUh0Z78RMJM5TUTCROHxZpqwrzEJWCmvfZ3C+ak+mb1xKWqr5WInvIXAIX31+A sgvOgn8GHYYokE94+DR+LubvX+9zFgqx/UNOCBElt6OGs49O1dARbNlq30APOdzH+ncY U5cmfQl9BmiKjnfuL4T3dC7+/q65on4bx9cPv3HeLH/4lI9v9V8M6eLogjqHbCPRDWxP DRAm9X/s9arjWyv7rVplmpEHLBhYso6/tsi/VHz2zmGhmU+eBeMnH15dz2gS3GPpwsmv V05Q== X-Gm-Message-State: AEkoouuOwfoPFuKNXcGTWVBR0w1J4M1KiryWot8D8FH+qLVm1yUA1RFbZHwbCGc5ITgRw+g84vf2lv2tvl9aZg== X-Received: by 10.194.238.170 with SMTP id vl10mr46080862wjc.18.1471453598851; Wed, 17 Aug 2016 10:06:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.43.135 with HTTP; Wed, 17 Aug 2016 10:06:08 -0700 (PDT) In-Reply-To: <57B44BCB.3010400@jonasschnelli.ch> References: <57B31EBC.1030806@jonasschnelli.ch> <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> <57B4113E.4010502@jonasschnelli.ch> <57B44BCB.3010400@jonasschnelli.ch> From: Marek Palatinus Date: Wed, 17 Aug 2016 19:06:08 +0200 Message-ID: To: Jonas Schnelli , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=089e014934ac106188053a477dbf 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:06:41 -0000 --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. > > > > > _______________________________________________ > 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
Hi,

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.

Currently the TREZOR prot= ocol works like device is a server and wallet is a client calling methods o= n it. It's like: "Sign this for me, please", "Ok, give m= e this information", "Here it is", "Now I need this ano= ther piece".... "There is the signature". Wallet does not kn= ow 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 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).

slush<= /div>

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 conf= igure
>> 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, 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 'nother discussion)
>
> 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.

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 betwe= en
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 th= e 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--