Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DE73E305 for ; Sun, 28 Aug 2016 23:14:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4FE4F10E for ; Sun, 28 Aug 2016 23:14:05 +0000 (UTC) Received: by mail-it0-f53.google.com with SMTP id d65so73133997ith.0 for ; Sun, 28 Aug 2016 16:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mwheKuEz8RtzuicPoeTUx9RgzJAQjkvet1Ik+K3ZvgM=; b=gRpW6tfGbNsLtvHFNC3ewiCfXGOAGtunHpgkTJjm8XDW02gR/OAwScyKqXNGBgHF+2 6zvZ383Eg8XuO3mT0mROVmgmWrpUrtYlAe66oc/8lg7Xf2hov6XiFveYAn01hXOP1Otx g+GnyiBc3BwMidYEfM/W61h8UMqKD2FiI9QU1HU3TvB0AWCFvTJEJpSZOOKr7MZLfqQ+ YvQlOghTngiiyaINQa2c9kXpMepf9NGBq1uBuH0l++lE4mz8Vyc/uzJ7kmY+c8HdU+vY y/OnRMid5qJg97Ue/aozzeBzMYQWItSts3S3QA6uxrbrIOooLn+u4BjMLOyhgC02Qo+q ewww== 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=mwheKuEz8RtzuicPoeTUx9RgzJAQjkvet1Ik+K3ZvgM=; b=BgjxpEn+A0P89y3Sh+o4I12Z9wME95kdJEGvl23aQwEFJTG0iPSw9JzpqhYX5VnvSR Ztra8LDhq2bjqD5i/9M5Sh2+pD4WL3E8fLJRMIQIYIqS7D4GPBGL9naN9X18CcZgv2wl J+AJU2lZ0ngG+Imxoy7y3lPWpIZ1lRlXTY6hcFw08/T0xMEnDgAU93rj3x/1pYlxmDBO SwzEsgnASNy+N65imuKYYBVPtW2p8Zqvyi+ISe2y3PF6aW9u6/H4sAj7aGJ7XCgudmQv +h2kS4OY6yRN4pCQpgvHkkLnJquP8FCPT5GnVQ69fKiHQdaycJZuh2UPNNXCqVEa5qt3 mLfw== X-Gm-Message-State: AE9vXwN7su0A0i1TVSH3XfO+PGhhtE5sHuPL2Rdqld9qZ1VnAAvsPvcHZWEsvqucuwzV/tJ0RVkU1xOgIrm7Ww== X-Received: by 10.36.227.78 with SMTP id d75mr10726585ith.75.1472426044666; Sun, 28 Aug 2016 16:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.73 with HTTP; Sun, 28 Aug 2016 16:14:03 -0700 (PDT) In-Reply-To: References: <57B31EBC.1030806@jonasschnelli.ch> From: Corey Haddad Date: Sun, 28 Aug 2016 16:14:03 -0700 Message-ID: To: Moral Agent , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c111de859b915053b29e73b X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 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: Sun, 28 Aug 2016 23:14:06 -0000 --94eb2c111de859b915053b29e73b Content-Type: text/plain; charset=UTF-8 *One of my biggest fears about using any wallet is the "whoops, cosmic ray flipped a bit while producing receiving address; SFYL!" possibility. For high value cold storage, I always generate my addresses on two independent machines using two different pieces of software. Am I nuts for doing that?* A randomly flipped bit would be extremely unlikely to yield a valid address, however, I still think it you are wise to use independent routes to confirm that your addresses match the keys. I do the same when I generating my cold storage key pairs. I think malicious address substitution is an under appreciated attack vector. Regarding this thread in general, would it make sense for this proposal to include standards for multi-sig wallet interoperability? A whole spectrum of attacks would be made less likely - and easy for typical users to guard against - by using wallets on separate devices AND where the wallet software was written and provided by different parties. On Mon, Aug 22, 2016 at 9:50 AM, Moral Agent via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It would be nice if the detached signer and the normal wallet could both > verify the correctness of generated addresses before you cause coins to be > sent there. > > e.g. the hardware wallet could give its master public key to Bitcoin Core > and you can thereafter generate your receiving addresses on Core, with the > option to have the HW wallet validate them. > > One of my biggest fears about using any wallet is the "whoops, cosmic ray > flipped a bit while producing receiving address; SFYL!" possibility. For > high value cold storage, I always generate my addresses on two independent > machines using two different pieces of software. Am I nuts for doing that? > > With the above scheme, you are pretty well protected from losing money if > your HW wallet is defective. You could still lose it if the HW wallet was > evil of course, but that strikes me as much more likely to be discovered > quickly. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c111de859b915053b29e73b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One of my biggest fears about using any wallet is = the "whoops,=20 cosmic ray flipped a bit while producing receiving address; SFYL!"=20 possibility. For high value cold storage, I always generate my addresses on two independent machines using two different pieces of software. Am I nuts for doing that?

A randomly flipped bit would be= extremely unlikely to yield a valid address, however, I still think it you= are wise to use independent routes to confirm that your addresses match th= e keys.=C2=A0 I do the same when I generating my cold storage key pairs.=C2= =A0 I think malicious address substitution is an under appreciated attack v= ector.

Regarding this thread in general, would it make se= nse for this proposal to include standards for multi-sig wallet interoperab= ility?=C2=A0 A whole spectrum of attacks would be made less likely - and ea= sy for typical users to guard against - by using wallets on separate device= s AND where the wallet software was written and provided by different parti= es.

On Mon, Aug 22, 2016 at 9:50 AM, Moral Agent via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
It would be nice if the det= ached signer and the normal wallet could both verify the correctness of gen= erated addresses before you cause coins to be sent there.

e.g. the hardware wallet could give its master public key to Bitcoin Core= and you can thereafter generate your receiving addresses on Core, with the= option to have the HW wallet validate them.

One o= f my biggest fears about using any wallet is the "whoops, cosmic ray f= lipped a bit while producing receiving address; SFYL!" possibility. Fo= r high value cold storage, I always generate my addresses on two independen= t machines using two different pieces of software. Am I nuts for doing that= ?

With= the above scheme, you are pretty well protected from losing money if your = HW wallet is defective. You could still lose it if the HW wallet was evil o= f course, but that strikes me as much more likely to be discovered quickly.=

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


--94eb2c111de859b915053b29e73b--