Return-Path: <ken@keepkey.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DD4D3721
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 May 2016 17:37:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com
	[209.85.192.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 465CD16A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 May 2016 17:37:04 +0000 (UTC)
Received: by mail-pf0-f171.google.com with SMTP id c189so54687631pfb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 May 2016 10:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=keepkey.com; s=google;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=SASXCSj19wgtzYIUeS5X8iCatmmAtEYCU6+43134rB0=;
	b=G3QKzmllRmYEuURP2Kkftesy4Q8TFkCbHjNVLblXZYi/L9UjJE+VC/z3ESiYEAN4i7
	TfZ7yA3somHu7JNUOqQ/8WaryFO0LcUgWnehSeUw3wgo2ZHrUgcvJpmsptgeIjRhjcqa
	ebrqY4FaQrwGP6dHkIXeYwwOebe8RXX3U/Fx0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=SASXCSj19wgtzYIUeS5X8iCatmmAtEYCU6+43134rB0=;
	b=PmwYQ+JJ1gZJps0INmqAu5Qw/egeumK7C7v59ddLuz6Qj1IU2zXRzjUCIN4ffTaS1o
	JSM8X1Hg1Hes5tM9ClZ9U2oPcOUV8Vn9wqGp0QOx0KkBb9/2z7DJsZX/0BolYlill/7c
	MnFKY8dZoNuI7cVBZzh8+tYPQ46A1vXM90v5HPHSopuQ8ISCiMKqT8WKDhJauZPSdue6
	UfLfFnKBUmAIeDVXKWQUshrUQYR0s1f346q++J1A6SQIw7DID3MgfQvj9zETgkQ1xsz/
	btB0nfqgyf5EceSghKuBamAyrg+T98qmZdic8FECyatLgr95H9oJFBuRBRxG724OCbOK
	fOnA==
X-Gm-Message-State: AOPr4FVLgXkAP/Mv2Wn4uGrEbRsd2pHCvxDRi4QrahiRnWnO65+vxqyEjmQCI8pfmLrBCw==
X-Received: by 10.98.18.80 with SMTP id a77mr32182385pfj.27.1463247424011;
	Sat, 14 May 2016 10:37:04 -0700 (PDT)
Received: from [10.0.1.18] (c-67-183-63-85.hsd1.wa.comcast.net. [67.183.63.85])
	by smtp.gmail.com with ESMTPSA id
	lz5sm35918966pab.34.2016.05.14.10.37.03
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Sat, 14 May 2016 10:37:03 -0700 (PDT)
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>
X-Mailer: Apple Mail (2.3124)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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
X-Mailman-Approved-At: Sat, 14 May 2016 17:39:18 +0000
Subject: Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 14 May 2016 17:37:05 -0000


> * 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=