Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0139092B for ; Wed, 24 Aug 2016 10:31:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from thomaskerin.io (static.204.212.9.5.clients.your-server.de [5.9.212.204]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id DF87A112 for ; Wed, 24 Aug 2016 10:31:34 +0000 (UTC) Received: from [10.137.3.17] (pool-108-28-164-248.washdc.fios.verizon.net [108.28.164.248]) by thomaskerin.io (Postfix) with ESMTPSA id 8BC6F11981090 for ; Wed, 24 Aug 2016 10:31:31 +0000 (UTC) To: bitcoin-dev@lists.linuxfoundation.org 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: Thomas Kerin Message-ID: <86fb234e-54b1-d7ec-cd8f-97f8840658e6@thomaskerin.io> Date: Wed, 24 Aug 2016 12:31:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ckc5xFo7o7AFwS3JoEMdKtm1lIxqgSQlh" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 24 Aug 2016 15:40:51 +0000 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, 24 Aug 2016 10:31:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ckc5xFo7o7AFwS3JoEMdKtm1lIxqgSQlh Content-Type: multipart/mixed; boundary="nikL78kOlXPJr0mn8Dqrlh7m0LV4umUH2" From: Thomas Kerin To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <86fb234e-54b1-d7ec-cd8f-97f8840658e6@thomaskerin.io> Subject: Re: [bitcoin-dev] Hardware Wallet Standard 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> In-Reply-To: --nikL78kOlXPJr0mn8Dqrlh7m0LV4umUH2 Content-Type: multipart/alternative; boundary="------------18535687597DE6451029934F" This is a multi-part message in MIME format. --------------18535687597DE6451029934F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I want to pitch a use-case that might have been ignored in this discussio= n: I don't think this protocol is only useful for hardware wallets. Technically any website that wants to request public keys/signatures and offload the responsibility for managing keys and signing to the user would also find this valuable. I hope we can move forward with a protocol that suits both the hardware people, and the people who find signing transactions in browsers unsettling. Maybe we the focus should move away from only servicing hardware, and asking if the motivation is better captured by "allow users pick their own ECDSA implementation, hardware or software", then working out what we need to get us there. On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote: > On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev > > 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 =96 as already mentioned =96 is we ACK to work= > together > on a signing protocol or if we NACK this before we even have starte= d. > > > 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 > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------18535687597DE6451029934F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I want to pitch a use-case that might have been ignored in this discussion:

I don't think this protocol is only useful for hardware wallets. Technically any website that wants to request public keys/signatures and offload the responsibility for managing keys and signing to the user would also find this valuable.

I hope we can move forward with a protocol that suits both the hardware people, and the people who find signing transactions in browsers unsettling.

Maybe we the focus should move away from only servicing hardware, and asking if the motivation is better captured by "allow users pick their own ECDSA implementation, hardware or software", then working out what we need to get us there.


On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote:
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 =96 as already mentioned =96 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 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.

--
Nicolas Bacca | CTO, Ledger 




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev

--------------18535687597DE6451029934F-- --nikL78kOlXPJr0mn8Dqrlh7m0LV4umUH2-- --ckc5xFo7o7AFwS3JoEMdKtm1lIxqgSQlh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXvXd4AAoJED6nkklm0EibBm4P/jbOG4SMilkgFqcBBNH5/ppl y3p8McJTm0visqkOAXLpmGeLvM5xkw8gdo+MsKUG98+m/bS0NWwSYteeoMC8yWNb mL4QCaX2j0uxCv4Y1VBqNjPc4pzl1vNOYaHpkiYE88QvVxo8VY+m0fKqxmSZjHRn Gc2IlHOF6ZNoxIMgBTfxw/XjeLSxisTlr1IUZZP9M3tIldRgJcbH/nskqtYaPlVb jbTtKqRUC6Y49rxMrVSXACPgdHofbQBmnyttugDO4QdUw4hDtRVyF/OELyo+oi+X wlIOcjXt7LY6TBHpaeggA2W9nu1okntdIXw3sZlvcZ6KRo7r5C+0FEzH3gz3n/3p cCi0RRdf7ClBFK3yUNBrGMEJgTAb0nV837hYMDmB5iM1It/EqRJ5XeeZj94+kg9/ wem5S31nBgjIm4Ql6yLKXMvfv/2rR0lYC9KMVjJhcN11MgpqF59RLXhS1fngC26V Qnf3RSQoihxpubtlhmPjIK/vCbcJ4Y10w54U7ryU0FvoXB+uKLnlwFrKtfuXR8Mt TY4bmdwIVENPwxyqPtiF8ChtS/7m4N7gyXwIqcaZgZI+AJxjHHT9W4CI1w0bAqKT 6oq4NwPzLhKphdEA8/IR3evr2itrjkEOzq1TId1z+4c3X3ACPNbH1mwf+fbpg2Jq doYkZsN2Cwe/CHn0YuwW =jyRT -----END PGP SIGNATURE----- --ckc5xFo7o7AFwS3JoEMdKtm1lIxqgSQlh--