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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1VaBRT-0004j2-QB
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Oct 2013 21:30:43 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.174 as permitted sender)
client-ip=209.85.223.174; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f174.google.com;
Received: from mail-ie0-f174.google.com ([209.85.223.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VaBRS-0004jg-MZ
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Oct 2013 21:30:43 +0000
Received: by mail-ie0-f174.google.com with SMTP id qd12so8795201ieb.33
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Oct 2013 14:30:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.16.68 with SMTP id e4mr3501611igd.12.1382823037265; Sat,
26 Oct 2013 14:30:37 -0700 (PDT)
Received: by 10.50.141.136 with HTTP; Sat, 26 Oct 2013 14:30:37 -0700 (PDT)
In-Reply-To: <CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com>
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>
Date: Sat, 26 Oct 2013 23:30:37 +0200
Message-ID: <CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: slush <slush@centrum.cz>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VaBRS-0004jg-MZ
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
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: Sat, 26 Oct 2013 21:30:44 -0000
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).
--
Pieter
On Sat, Oct 26, 2013 at 10:47 PM, slush <slush@centrum.cz> wrote:
> Hi Thomas,
>
> can you more elaborate on that "version" bits? What is exact meaning of it?
> I still think this is more an implementation problem. What stops Electrum to
> do the same algorithm for searching branches as it is now for used
> addresses?
>
> These "version bits" need to be covered by the specification as well,
> because if any client will use them differently (or won't use them at all),
> it will break cross-compatibility between clients, which was another goal of
> bip39.
>
> Marek
>
>
>
>
> On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
>>
>> here is a simple implementation, with some ideas on how to format the
>> metadata:
>> https://en.bitcoin.it/wiki/Talk:BIP_0039
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
