summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Voegtlin <thomasv@electrum.org>2016-08-24 14:51:32 +0200
committerbitcoindev <bitcoindev@gnusha.org>2016-08-24 13:27:11 +0000
commitba57f30d926edd01f365f23a2681b7ee7b5e08f2 (patch)
treeaab1eed521d169178f410601d100b233b697ca1d
parentdeb5f0e46f578608e5f74b6c31941d9ab4b95546 (diff)
downloadpi-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/72f75ac9d228b62608b96b867a76e8cb04dc45193
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--
+