Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Kenneth Heutmaker <ken@keepkey.com>
In-Reply-To: <57374EF3.3000705@jonasschnelli.ch>
Date: Sat, 14 May 2016 10:37:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <793CC6DA-60C2-492F-A758-957CD3387828@keepkey.com>
References: <5735D3A4.7090608@mycelium.com> <5735EC17.5040901@satoshilabs.com>
	<CACq0ZD4BvvCryYmO-J9Rof-ogQJ1wNLgmUEU596nuTH=-U8Hag@mail.gmail.com>
	<5735FC99.5090001@satoshilabs.com>
	<CACq0ZD7mLCaoGpcVEp7NfW=6nsEA39tZp+G8oeySygMEyhuwQA@mail.gmail.com>
	<57361577.7060207@satoshilabs.com>
	<CACq0ZD7BUaMnRgpx0ZxZu1Ok5weiJ9tbZnyFpXEHsTi==V_t_w@mail.gmail.com>
	<5736DEEA.5030603@jonasschnelli.ch>
	<57373116.90902@satoshilabs.com>
	<57374EF3.3000705@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Precedence: list


> * 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=92t =
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 =93old=94 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=92t, implementing it is straight =
forward if it already implements BIP32. It=92s 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 =92noise=92 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=92t 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.

=97
Ken Heutmaker, KeepKey=