diff options
author | Thomas Voegtlin <thomasv@electrum.org> | 2016-08-24 14:51:32 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-24 13:27:11 +0000 |
commit | ba57f30d926edd01f365f23a2681b7ee7b5e08f2 (patch) | |
tree | aab1eed521d169178f410601d100b233b697ca1d | |
parent | deb5f0e46f578608e5f74b6c31941d9ab4b95546 (diff) | |
download | pi-bitcoindev-ba57f30d926edd01f365f23a2681b7ee7b5e08f2.tar.gz pi-bitcoindev-ba57f30d926edd01f365f23a2681b7ee7b5e08f2.zip |
Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
-rw-r--r-- | 32/72f75ac9d228b62608b96b867a76e8cb04dc45 | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/32/72f75ac9d228b62608b96b867a76e8cb04dc45 b/32/72f75ac9d228b62608b96b867a76e8cb04dc45 new file mode 100644 index 000000000..e8d2319f4 --- /dev/null +++ b/32/72f75ac9d228b62608b96b867a76e8cb04dc45 @@ -0,0 +1,193 @@ +Return-Path: <thomasv@electrum.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6097B483 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Aug 2016 13:27:11 +0000 (UTC) +X-Greylist: delayed 00:28:34 by SQLgrey-1.7.6 +Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 7230E1E2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Aug 2016 13:27:10 +0000 (UTC) +Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net + [217.70.183.198]) + by slow1-d.mail.gandi.net (Postfix) with ESMTP id 3D87747BD5D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Aug 2016 14:52:09 +0200 (CEST) +Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) + by relay6-d.mail.gandi.net (Postfix) with ESMTP id AF5F5FB8B8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Aug 2016 14:52:04 +0200 (CEST) +X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net +Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) + by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) + (amavisd-new, port 10024) with ESMTP id CcPF0GKlmbID + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Aug 2016 14:51:33 +0200 (CEST) +X-Originating-IP: 178.19.221.38 +Received: from [10.10.42.121] (unknown [178.19.221.38]) + (Authenticated sender: thomasv@electrum.org) + by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id DFA66FB8EA + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Aug 2016 14:51:32 +0200 (CEST) +To: bitcoin-dev@lists.linuxfoundation.org +References: <201608232012.12588.luke@dashjr.org> +From: Thomas Voegtlin <thomasv@electrum.org> +Message-ID: <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org> +Date: Wed, 24 Aug 2016 14:51:32 +0200 +User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 + Thunderbird/45.2.0 +MIME-Version: 1.0 +In-Reply-To: <201608232012.12588.luke@dashjr.org> +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; + boundary="agOisqevXgPn0K7qngdoRAkVcGpeQMFtB" +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 +Subject: Re: [bitcoin-dev] BIP Status updates (including to Active/Final + Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 +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: Wed, 24 Aug 2016 13:27:11 -0000 + +This is an OpenPGP/MIME signed message (RFC 4880 and 3156) +--agOisqevXgPn0K7qngdoRAkVcGpeQMFtB +Content-Type: multipart/mixed; boundary="0dptqkpxmdk7p9erhnHGA25XE1EmQMBvJ" +From: Thomas Voegtlin <thomasv@electrum.org> +To: bitcoin-dev@lists.linuxfoundation.org +Message-ID: <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org> +Subject: Re: [bitcoin-dev] BIP Status updates (including to Active/Final + Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 +References: <201608232012.12588.luke@dashjr.org> +In-Reply-To: <201608232012.12588.luke@dashjr.org> + +--0dptqkpxmdk7p9erhnHGA25XE1EmQMBvJ +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: quoted-printable + +Le 23/08/2016 =E0 22:12, Luke Dashjr via bitcoin-dev a =E9crit : +> BIP 39: Mnemonic code for generating deterministic keys +> - Used by many wallets and hundreds of thousands of users. +>=20 +> BIP 44: Multi-Account Hierarchy for Deterministic Wallets +> - Appears to be implemented by multiple wallets. +>=20 + +I personally believe that BIP39/BIP44 is a bad design. There is limited +support for these BIPs in Electrum, in order to provide compatibility +with hardware wallets. However, I do not plan to use BIP39/BIP44 for +default Electrum wallets, for the following reasons. + +(Note that it does not make sense to consider BIP39 and BIP44 +independently. Any wallet that decides to implement one without the +other would be considered as broken.) + +Here is why I rejected this design: + +1 - BIP44 uses multiple accounts. This means that in order to be +compatible with the standard, a wallet *must* implement multiple +accounts. A wallet that decides to keep things simple and use only one +account, will not allow users to recover all their funds when they +restore from a BIP39 seed, and will be considered as broken. + +2 - An appealing feature of deterministic wallets is that you can use +the same instance of your wallet on different devices. Two instances of +your wallet can automatically synchronize their Bitcoin addresses, and +display the same balance. The problem is that hardened derivations break +this property. Indeed, with hardened derivations, software wallets need +to ask the user's password in order to derive new accounts. Therefore, +in order to implement automated detection of newly created accounts, a +BIP44-compatible software wallets would need to ask the user's password +whenever a new account is detected. This means that the wallet would ask +the password without the user initiating any action. This seems to be an +avenue for malware. + +Of course, hardware wallets do not have that issue, because they can +derive new accounts without requesting a password from the user. BIP44 +is a standard that has been designed for hardware wallets, but that +makes things really difficult for software wallets. + +3 - Unneeded complexity. From an end user perspective, the multiple +accounts in BIP44 achieve the same result as using different derivation +passphrases with the same BIP39 seed phrase. The only real difference is +that BIP44 accounts can be enumerated deterministically, while +passphrases in general cannot. However, this property is of limited +interest, because automatic synchronization of multiple accounts cannot +be guaranteed for bip44 software wallets, as explained in 2. + +4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed +phrase' in order to derive the BIP32 seed. This hash-based derivation +was added on my suggestion, in order to make the BIP independent from +the particular wordlist used to generate the seed phrases. However, +BIP39 also requires the implementation of a checksum, in order to verify +that a seed phrase is valid. Suprisingly, the specification of the +checksum involves wordlist indices. This means the checksum (and thus +the BIP) requires a fixed wordlist. This defeats the purpose of using a +hash for the derivation of the seed. + +The authors of the BIP should either have used hash functions for both +the seed AND the checksum (that is what Electrum does), or for none of +them (in that case case, you can have a bidirectional function between +seed phrases and entropy, which is nice if you want to perform Shamir +secret sharing of seed phrases, at the expenses of a fixed wordlist). In +its current state, BIP39 takes the worst of both worlds. + +5 - The fact that the wordlist must be part of BIP39, and cannot be +changed in the future, seems a terrible idea to me. I believe that a +specification should always try to be minimal. In that case, the +specification includes a 2000+ words dictionary, when it could have +avoided that. + +Even if you decide that BIP39 is final, there will always be users +requiring the addition of wordlists for new languages. So, in practice, +this BIP will never be final. + +6 - Finally, and most importantly, BIP39 seed phrases do not have a +version number. Without a version number, how are you going to derive +addresses from a BIP39 seed phrase, when wallets start to use to new +derivation methods (such as SegWit, or Schnorr signatures)? Does it mean +that a BIP39 compatible wallet will have to check addresses from all the +derivation methods that ever existed in the past, in order to ensure +that all coins are correctly retrieved? Or will there be users that +cannot access their coins because their BIP39 seed phrase is too old for +newer software? + + +--0dptqkpxmdk7p9erhnHGA25XE1EmQMBvJ-- + +--agOisqevXgPn0K7qngdoRAkVcGpeQMFtB +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: OpenPGP digital signature +Content-Disposition: attachment; filename="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2.0.22 (GNU/Linux) + +iQIcBAEBCgAGBQJXvZhUAAoJECvVgkt/lHDmVtwQAIHC/3w70S8N7wj5vpMqlcle +zppgR+OTZFwndOOBg5NB+S9xaKVT7QHA/8WswFP0i5bJsIUafLHEkTwsQUVHk6fr +elcbYNu5KenNnIKDQUNAVGH/nCdlrI0uZAko5fSyW5FuhNkj90cZ+N8AzYQW/PIr +4KJOlSqq9NS4YVDLBha5Kv2d2qCN5RJ/kdhhhlYDfVo/MIMKguiY7J1UyBb3X7nJ +w0wZNl3oM6exzo80qBNRwtis6OiaSbUFOst6tbcH+uWM/Kw7ByEeNtfoUQgaKead +MQGgQfgdLj+w8lY0Dl/lyjDMAJOpN69wh4N3DPi9g1N4GZxZpEQGikRpBbAoFblP +LXELC9/FSxm+z1hG36Xbh7zuqDv75ViU9ZcOVuUEys5S7bx1tC5I5sh0aJz/HGr+ +REdKclsDReJK9FPbPyrZil5mAJk4PW4542AOTfWwcu/s7x/GeiDQpC8b98rafs82 +Xie6H9P6qgjO6TkXSawK9ZuztnabNUgfXnLOth6kXYlZ1A7g3reNte1J0C2tGe3w +VthAEuhmOYaRNsfgG8Cj07Xxzdy1toLnf5gKG2tdLpxwdTd2EkWauxakWwx3ZYvF +lDF0P8AC33vab0N0YMFeFf1bvd8cYRGEDjDX2+aiFr5pWfB1mDPH/G3tEFZ3vUKv +XADa85HwdC+jtB49RMgE +=3db2 +-----END PGP SIGNATURE----- + +--agOisqevXgPn0K7qngdoRAkVcGpeQMFtB-- + |