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 22277941 for ; Wed, 17 Aug 2016 00:03:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DA710199 for ; Wed, 17 Aug 2016 00:03:02 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id pp5so30764711pac.3 for ; Tue, 16 Aug 2016 17:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=i/oMVWjeqCAYY8w2OY8xQUQSN/fic2qtomTpeYIiHNU=; b=zxOGj/GhrMnzyUZDTnB+96n88BSkZAticSM14bMem/has9o2Sj2/jGsMzNv87HxCiP YGbzB1XevKsTWlOcdgRIEVADH71/KJJupwhm3heKhbKZslix2ktnsiP8IbZD2CgCt6h/ xw8ucI+0TfFKRYapHbZwhJKN75K4twUbP3DCyufmGvfvDrEPX7J3utF9tpo0l7+9JapD L3gAg0bd0woGeow/M1wnAdBsH8WAc5iU1/O1/7OrPeuAyQLpXu5ehzxS3agXI1NPjbWw GI7cmWLFN89cSnq8nm3I+Vp4/wtEYrEpFUb2RWbMi7MBKxRzmDXjExXVXoTg3d+v3AZ7 COvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=i/oMVWjeqCAYY8w2OY8xQUQSN/fic2qtomTpeYIiHNU=; b=OjahxcsW5QrPUoxQTPng8D6PR/dmYwfY/7xUjkmGIrVv+IU6EOGirhfUwPl5uDuHhP tvCr6kypyHZKGC5EBwsNqnSVQnl49sJbhuvoFXczcXHZg5l88w10FXIcF6WuI/Ab4fuz JoHKxLtqchS7jqBrlImyNzGR81wXw7MCkhqjEDTPH7hOCY5ka/G0tRhBl52wCciCmQkz qjBb8BE3+U/jwN4aulh3+NGyM8LBNap4qXbKlWrFBpdtxT/EUJt7IqyTPxzT6IdCBLCx FtHS0v7qfdU9LzvWDc6gvd2kFUtolaCzMWreLYyHiq9PZsCzecfgBBBEDtJriJcsXszJ Qu5w== X-Gm-Message-State: AEkoouuZuhoZ4rN5mIsfCWS0dTSF4wOHIwqtf9A88vaiSbIbEAtreT72v5o3xYECq0UPcQ== X-Received: by 10.66.72.106 with SMTP id c10mr29440070pav.18.1471392182244; Tue, 16 Aug 2016 17:03:02 -0700 (PDT) Received: from ?IPv6:2601:647:4080:237:25eb:9343:ea9c:230b? ([2601:647:4080:237:25eb:9343:ea9c:230b]) by smtp.googlemail.com with ESMTPSA id bx9sm42108941pab.17.2016.08.16.17.03.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 17:03:01 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <57B31EBC.1030806@jonasschnelli.ch> <201608161922.30588.luke@dashjr.org> From: Thomas Daede Message-ID: <3a183d3a-757c-ec32-0bd1-c3f8a1982edd@gmail.com> Date: Tue, 16 Aug 2016 17:03:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <201608161922.30588.luke@dashjr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no 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, 17 Aug 2016 00:21:28 +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, 17 Aug 2016 00:03:03 -0000 On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote: > It would be best if the hardware protocol were standardised, so the user > doesn't need a plugin of *any* sort... I notice some hardware wallets have > begun to implement (or reuse) Trezor's interface, so that would seem a good > place to start? I also agree with this - the user experience would be a lot better without the need to install custom adapter software, especially for the desktop case. There could be two layers to the specification - the raw messages that need to be passed, and the transport mechanism to pass them (USB HID, QR code, audio...). For the most common case (USB), both layers could be defined, and other transports could be added later. This split already exists in the draft specification, though it's not very clear (URIs include return URIs that don't make sense for a pipe, for example). The existing URI scheme, while allowing disambiguate by manufacturer, provides no way to to enumerate available manufacturers or enabled wallets. This means that the "driver" would have to include a GUI to select this. Also, passing return URIs seems rather fragile - are there any other examples of protocols that use URIs for bidirectional IPC? Thomas