From: Corey Haddad <corey3@gmail.com>
To: Moral Agent <ethan.scruples@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Date: Sun, 28 Aug 2016 16:14:03 -0700 [thread overview]
Message-ID: <CAK_HAC-AeJPDa6+SU3wPtnP_UJ_WciyhYZAu9F7_6S02ZGZvaA@mail.gmail.com> (raw)
In-Reply-To: <CACiOHGycQKr3zETzhOfxzOFb2FgqOou_3bod66NuPWbf=4hhEQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
*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
>
>
[-- Attachment #2: Type: text/html, Size: 2893 bytes --]
prev parent reply other threads:[~2016-08-28 23:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-16 14:10 [bitcoin-dev] Hardware Wallet Standard Jonas Schnelli
2016-08-16 14:48 ` Pavol Rusnak
2016-08-16 15:13 ` Jonas Schnelli
2016-08-16 15:21 ` Pavol Rusnak
2016-08-16 17:48 ` Jochen Hoenicke
2016-08-17 0:25 ` Thomas Kerin
2016-08-17 7:24 ` Jonas Schnelli
2016-08-17 7:40 ` Nicolas Bacca
2016-08-17 10:13 ` Dana L. Coe
2016-08-17 11:34 ` Jonas Schnelli
2016-08-17 17:06 ` Marek Palatinus
2016-08-18 6:54 ` Jonas Schnelli
2016-08-18 9:15 ` Marek Palatinus
2016-08-18 9:35 ` Jonas Schnelli
2016-08-18 9:43 ` Marek Palatinus
2016-08-18 9:49 ` Jonas Schnelli
2016-08-18 10:23 ` Nicolas Bacca
2016-08-24 10:31 ` Thomas Kerin
2016-08-16 19:22 ` Luke Dashjr
2016-08-17 0:03 ` Thomas Daede
2016-08-16 23:36 ` Aiqin Li
2016-08-17 0:14 ` Peter Todd
2016-08-17 7:27 ` Nicolas Bacca
2016-08-17 18:36 ` Bryan Bishop
2016-08-22 16:50 ` Moral Agent
2016-08-28 23:14 ` Corey Haddad [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK_HAC-AeJPDa6+SU3wPtnP_UJ_WciyhYZAu9F7_6S02ZGZvaA@mail.gmail.com \
--to=corey3@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=ethan.scruples@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox