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 28C0E412 for ; Thu, 18 Aug 2016 10:23:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yb0-f177.google.com (mail-yb0-f177.google.com [209.85.213.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BD3810E for ; Thu, 18 Aug 2016 10:23:23 +0000 (UTC) Received: by mail-yb0-f177.google.com with SMTP id d10so4044002ybi.1 for ; Thu, 18 Aug 2016 03:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ledger-fr.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ESbrC2245RxfzWXLXQcAGENW1ICnNu4lDIbsFa9NJMI=; b=XQUAQ/gfaCeMwu1C2nllKdPpEBzP/3RUnnKf/K2zO4AuMy1EmVUcztctZifGz0sW1f QtJGpYgc9qH8B+9vFXz5xoSzdiu45agn9TVNx1njOiUP2aghXUzIZxfo4kA36Kx4Yi5q pRb9Q/9xUG0V+VDuu+/fhJyVLiPEeby4p/EeayYjB50bDEN6xpg/V0OXyzgaLaA/eFkv 3wkqMwRv3N+XC53X7FuvAEmOAYOA8IyDD8fQ2SV6Tj7JKB6Bgfqkfmx3HcUmRrJQQsXB EAxrM5BeQgQxPowl9zIyh2J4UnWaMaFSXNzKb3hJdf0DRmfKyczCExv98y3DDOrZPL03 NtZw== 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; bh=ESbrC2245RxfzWXLXQcAGENW1ICnNu4lDIbsFa9NJMI=; b=Vl92ELpzvPRM6hrp4t/nTs2zWcuFZn6olnbMvF48wN7mSCfUtwD5S8m1S4fZMLi2Vr rOZWvunj/hkrxU0Vp0u9hySgzcKBMEbjYIqiVgWjFIyeTcWn006QntAb/CZfOcTTwpHg kmQE/Et6YhmlG2WTRfpufzVYbjApu/J2G+U7YMK3vTUoY7kC/OnG4njOvXmi0/yV/8Qi SBcT0QMPvVqONtnTgltJcIbVoLKS3LRE5AJ6oNMjY8jcBVEnk9/JQ9YV9rK0I1GtUjcZ lqJ2yZvGnTV1GLED7Ml5B9hA1gBtVd9ViIab0lTCvdSNxVhkFNx+arqJAsNwEkx44raE mBPQ== X-Gm-Message-State: AEkoousY6p55hoHJcNaOyIFEdhGpzl96EvoAJO3VvEYlcFSyCGgF2dxEkYeZrL0DGMzHT+ozp4q7easxk0/NvA== X-Received: by 10.37.96.131 with SMTP id u125mr940686ybb.143.1471515802273; Thu, 18 Aug 2016 03:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.157.73 with HTTP; Thu, 18 Aug 2016 03:23:21 -0700 (PDT) In-Reply-To: <57B584BF.7000004@jonasschnelli.ch> References: <57B31EBC.1030806@jonasschnelli.ch> <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> <57B4113E.4010502@jonasschnelli.ch> <57B44BCB.3010400@jonasschnelli.ch> <57B55B8C.1070001@jonasschnelli.ch> <57B58149.8000200@jonasschnelli.ch> <57B584BF.7000004@jonasschnelli.ch> From: Nicolas Bacca Date: Thu, 18 Aug 2016 12:23:21 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a1143e548ad3ac8053a55f888 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: Thu, 18 Aug 2016 10:23:24 -0000 --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
On T= hu, 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<= br> > primary source of workflow management) goes directly against your
> proposal of wallet software as an workflow manager. So it is clear NAC= K
> for me.

The current question =E2=80=93 as already mentioned =E2=80=93 is we = ACK to 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 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.

--
Nicolas = Bacca | CTO, Ledger


--001a1143e548ad3ac8053a55f888--