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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thomasv1@gmx.de>) id 1VboK8-0005Vm-BY
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 09:13:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de
designates 212.227.17.21 as permitted sender)
client-ip=212.227.17.21; envelope-from=thomasv1@gmx.de;
helo=mout.gmx.net;
Received: from mout.gmx.net ([212.227.17.21])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1VboK7-00017A-17
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 09:13:52 +0000
Received: from [192.168.1.27] ([86.73.30.143]) by mail.gmx.com (mrgmx001)
with ESMTPSA (Nemesis) id 0MXZ4Q-1V7drq1b3m-00WShv for
<bitcoin-development@lists.sourceforge.net>;
Thu, 31 Oct 2013 10:13:44 +0100
Message-ID: <52721F47.30206@gmx.de>
Date: Thu, 31 Oct 2013 10:13:43 +0100
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09> <CAJna-HjgpRhLdVGh+prx54VezHaH1vXGpPotW1Xkz2tiAiWrbg@mail.gmail.com> <526BDEC2.2090709@gmx.de> <CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com>
<CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
In-Reply-To: <CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:5OE17+39h4OP56YY4FyH2QRXFK7oOR3SBCz7C7jZnsjFui5n9oI
Rq0hnKeOJ22hNHnC3uO6+yAK2c0peOIU4wARI6pIVS+Rl+umiPqg5q1pGOkPRgsdnWSLe/V
BImPcEwZZVXO9K0iJazzZFk1ze0H0G0DXFF8vvFzIci0Ike2aadXbXEXcsj5dZA2ljxeK6+
vtE8w+4HQmYIMw0rXKt4w==
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.17.21 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(thomasv1[at]gmx.de)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (thomasv1[at]gmx.de)
X-Headers-End: 1VboK7-00017A-17
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2013 09:13:52 -0000
Indeed, I want to include a version number in the seed phrase because
there are
multiple ways to define the tree structure used with BIP32. It is
certainly too early
to make final decisions on that, or to achieve a common standard.
Also, I can imagine that bip32 itself might be superseeded in the future.
I understand that encapsulating a version number in the seed phrase might
not be as important for other wallets as it is for Electrum. So it is
probably not
necessary to propose another BIP for that. I will simply implement it
for Electrum,
and I will try to do it in such a way that other wallets can use the
same format.
The other question we might be solving is strenghtening (your proposal).
I consider
that this is not a strong requirement for Electrum, because it does not
let the user
choose their seed phrase. However, if a few bits of the seed phrase are
allocated
for metadata, then I guess strenghtening can be part of it. That's
another good
reason to have a version number encapsulated in the seed.
I too wonder why the transformation needs to be bidirectional in bip39.
Le 26/10/2013 23:30, Pieter Wuille a écrit :
> Let's first try to agree on what we are solving.
>
> It seems that Thomas wants - in addition to the cryptographic data -
> to encode the tree structure, or at least version information about
> what features are used in it, inside the seed.
>
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
> structures. I do think we first need to see what possibilities and
> developments are possible related to it.
>
> In addition, information about the wallet structure is strictly less
> secret than the key data - it is even less confidential than address
> book data, transaction annotations, labels and comments and
> bookkeeping information. It could be backed up anywhere and everywhere
> without any repercussions, as far as I can see. I understand that in
> the case of Electrum, there is a strong reason to want this
> encapsulated together with the seed, but it's not really a requirement
> for most wallets.
> (if really needed, any key derivation scheme that starts from random
> strings can be augmented with metadata by enforcing property-bits on a
> hash of the string (so not of the output), as this data doesn't need
> protection from brute-forcing).
>
> Regarding other requirements, I wonder why we want the transformation
> to be bidirectional? If it is just about generating master seeds, one
> direction should be enough, and allows far nicer properties w.r.t.
> security. If we do settle on a standard for 'brainwallets', I would
> strongly prefer if it had at least some strengthening built-in, to
> decrease the impact of worst-case situations.
> If the reason is backward-compatibility, I think that any client that
> supports seeds already can just keep supporting whatever they
> supported before. Only if it matches both encoding schemes (as
> mentioned before) there is a potential collision (and in that case,
> the user could just be asked).
>
|
