From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DD4D3721 for ; 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 ; Sat, 14 May 2016 17:37:04 +0000 (UTC) Received: by mail-pf0-f171.google.com with SMTP id c189so54687631pfb.3 for ; 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 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> <5735FC99.5090001@satoshilabs.com> <57361577.7060207@satoshilabs.com> <5736DEEA.5030603@jonasschnelli.ch> <57373116.90902@satoshilabs.com> <57374EF3.3000705@jonasschnelli.ch> To: Jonas Schnelli , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=