public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kenneth Heutmaker <ken@keepkey.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Date: Sat, 14 May 2016 10:37:02 -0700	[thread overview]
Message-ID: <793CC6DA-60C2-492F-A758-957CD3387828@keepkey.com> (raw)
In-Reply-To: <57374EF3.3000705@jonasschnelli.ch>


> * What if the "old" wallet has used more then 1000 addresses? I guess
> some wallets do not even create a lookup window up to 1000 addresses.
> There is a high chance of loosing funds when doing sweep (move all funds
> to a new wallet) operation.

If that is the case, the wallet is not following the standard. The wallet hierarchy standards like BIP44 specify how to walk an address chain. They all specify that you should keep going until you don’t find any more used keys within the lookup window. If a wallet leaves gaps that are too big, that is also not compliant.

In any case, if the sweeping wallet understands how the “old” wallet uses the hierarchy, it can be safely swept without a potential loss of funds.

> * I guess most or maybe all wallets will keep all keys (the
> "lookup-window" keys) in the wallet database which could affect
> performance [4]

Yes, wallets with more addresses take more time to process.

> * I guess most wallets do not offer "moving the funds to a new seed" [5]
> which results in not solving the problem of a "lost" or "compromised"
> wallet and implies wrong security to the enduser.

Some wallets do and for those that don’t, implementing it is straight forward if it already implements BIP32. It’s just a matter of knowing how the old wallet uses the hierarchy and prioritizing the work.

> * If I import a bip39 mnemonic into a hardware wallet (assume Trezor or
> Keepkey) I have to type in the words into my computer which bypasses
> some of the security my hardware wallet provides me (MITM seed attack).
> Together with the point above this reduces the security of a wallet (in
> particular cold storage significant).

Both TREZOR and KeepKey have developed strategies to prevent MITM attacks during seed recovery. TREZOR asks for the words in a random order and in some cases, adds ’noise’ words. KeepKey uses a rotating substitution cipher.

> I just wanted to point out that importing a wallet is a tricky step
> especially cross-wallet imports (I think cross wallet imports is an
> experts job without further improvements).

I don’t think it is as hard as you think. If a wallet uses BIP32 HD, all of the hard code is already implemented. It is just a matter of stringing the correct sequence of steps together.

Also, if the new hierarchy is under a separate purpose code as specified in BIP43, there is no need to create new seed. The BIP44 hierarchy and the new hierarchy can be extended from the same seed.

—
Ken Heutmaker, KeepKey

  reply	other threads:[~2016-05-14 17:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13 13:16 [bitcoin-dev] Bip44 extension for P2SH/P2WSH/ Daniel Weigl
2016-05-13 15:00 ` Pavol Rusnak
2016-05-13 16:03   ` Aaron Voisine
2016-05-13 16:11     ` Pavol Rusnak
2016-05-13 16:59       ` Aaron Voisine
2016-05-13 17:57         ` Pavol Rusnak
2016-05-13 21:42           ` Aaron Voisine
2016-05-14  8:16             ` Jonas Schnelli
2016-05-14 12:26               ` Jochen Hoenicke
2016-05-14 14:07               ` Pavol Rusnak
2016-05-14 16:14                 ` Jonas Schnelli
2016-05-14 17:37                   ` Kenneth Heutmaker [this message]
2016-05-15  8:53                   ` Thomas Voegtlin
2016-05-15 10:04                   ` Pavol Rusnak
2016-05-15 12:08     ` Daniel Weigl
2016-05-15 17:36       ` Aaron Voisine
2016-05-14  7:00 ` Andreas Schildbach
2016-05-14 14:08   ` Pavol Rusnak
2016-05-14 17:09     ` Aaron Voisine
2016-05-14 12:15 ` Jochen Hoenicke

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=793CC6DA-60C2-492F-A758-957CD3387828@keepkey.com \
    --to=ken@keepkey.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dev@jonasschnelli.ch \
    /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