1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
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=
|
