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 C7C7C8B1 for ; Wed, 17 Aug 2016 11:34:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0AFCD17D for ; Wed, 17 Aug 2016 11:34:42 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id C9EB22E60612; Wed, 17 Aug 2016 13:34:41 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro-2.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id 044682D001BD; Wed, 17 Aug 2016 13:34:39 +0200 (CEST) To: "Dana L. Coe" , Bitcoin Protocol Discussion References: <57B31EBC.1030806@jonasschnelli.ch> <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> <57B4113E.4010502@jonasschnelli.ch> From: Jonas Schnelli Message-ID: <57B44BCB.3010400@jonasschnelli.ch> Date: Wed, 17 Aug 2016 13:34:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wCTk9xjvjKcSEAeABAlPkp2GdRVfKSC6n" 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 11:34:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wCTk9xjvjKcSEAeABAlPkp2GdRVfKSC6n Content-Type: multipart/mixed; boundary="UHQ17xuDfiuDle6Gx1dd8SBc4tqjpSBPN" From: Jonas Schnelli To: "Dana L. Coe" , Bitcoin Protocol Discussion Message-ID: <57B44BCB.3010400@jonasschnelli.ch> Subject: Re: [bitcoin-dev] Hardware Wallet Standard References: <57B31EBC.1030806@jonasschnelli.ch> <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> <57B4113E.4010502@jonasschnelli.ch> In-Reply-To: --UHQ17xuDfiuDle6Gx1dd8SBc4tqjpSBPN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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). >=20 > Hi everybody, just thought I=92d throw my opinion in here. >=20 > 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=92s ProtoBuf. The commands and transaction d= ata is in a =93schema=94 which is then encoded in different methods acces= sible via ProtoBuf (depending on the data being sent). The advantages of = this protocol is that it can be implemented on a wide variety of platform= s. (but that=92s a whole 'nother discussion) >=20 > The URI would be handled waaaaay up in the specific application (such a= s the mytrezor wallet software or the various standalone wallets) - nowhe= re 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 =96 at the en= d =96 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. --UHQ17xuDfiuDle6Gx1dd8SBc4tqjpSBPN-- --wCTk9xjvjKcSEAeABAlPkp2GdRVfKSC6n 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 iQIcBAEBCAAGBQJXtEvMAAoJECnUvLZBb1Ps3vIP/2ymnr6yvM5NSx9TH0Sk74ft 46tPgFYsIoXo+onvhQ4bW6mx3SYbGrieBe47dLPwbrnaxU6lfEtys54IiVSBurFF U6zzTVSui66DNkBbPtvRkl1uIN1fNODUtcPgfjWAkibA7nws8Dx+FB+yM6asb4gf 81g/HSm3hXsflaUftm0cQ2IiA4CAlkEvuT0IU/bf2PGkT1FouROvUcrBQxpsIyB+ JnL2yIBfoDBQ6/WAx3wuvGrbgHCREWsyTxBesLv9MzeljYxSPrdfn1QHzZSLx9rW 3VpriKNWoNbbwa1epS9f20fFkz6RuPHkaqzEX9wMCfWIga+LqD45L+VFPdv4mhwE J6VDHvZrsw86ykb5XnMAAoKSFfI9QFZyxeTU6aXNArIFfQhw59xNEVgxP+mQpMBz cLa26tr1zI9keG69hbTnnhzc5ETLKmJXg12Wosu4NZXA2qu8KszYp174UAOFlCSg eZEemIAPrG6KNWVFl2uTUIcZwpO6wV5VNf5aX7+fRrt7dZEus1RyTRWFycgMRFih TieYXWSJ+1H0oCXBAeZDNGTCqnd1EqtEsM2hqnJYz+HBZzCme44mNc367d0PVNz3 HaBvnVzBhtUJr5wM6cs2E0IG5DJYz02wFBVoSZ9iv9vA5lZRokdtevdUapxHITGc T5pvf3OJ4LGNSHqGlZYh =x2IO -----END PGP SIGNATURE----- --wCTk9xjvjKcSEAeABAlPkp2GdRVfKSC6n--