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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
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--
|
