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
|
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 <stick@gk2.sk>) id 1WNpOO-0007yr-3f
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 20:04:44 +0000
X-ACL-Warn:
Received: from mail-ea0-f169.google.com ([209.85.215.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WNpOM-0000f3-7t
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 20:04:44 +0000
Received: by mail-ea0-f169.google.com with SMTP id h14so70927eaj.14
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Mar 2014 13:04:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=Xs7m41okW+eIDrCIoNCWe69b3U2Tv54IrhkG+PaNDYg=;
b=IIwyOzG41FdfnoStnwIUXgRPrwqGlH4G/v4CvAtiSv02I7/FB/Sfp+mubFr0b7ZfHa
DnmuikBZmFgFJJSP1HhBEth6z+cHIBM892Akzd9GjL6s8QvSU+N0h/waQL77Ujl5TlgH
Sw1Mi0YSqeab1Ppp2DW+klFUdg5Bjju/S9e8hxf87T2wgHSIN/MvKOC/jUI/6g0KjwxH
xllBlB355mDPC8LayeiLMYAhH4jP0EfQO6ji+tlSZIINO8oy+1XJ5K5WcjvBhHTYoSHH
ca94COwtD4hooKJ5fHCUAfaxs5pg3uuBf/HlkKfqj+P1VwehYRt3XFI8G7IMFN6WZ7CR
BBYg==
X-Gm-Message-State: ALoCoQkPDqJ1GL+SFOY621t31srqBb1GacmY4TYB42wRqVYSKeKsxUynk15yEXZFqRQQecGT4L5Y
X-Received: by 10.14.111.201 with SMTP id w49mr5162354eeg.92.1394654675916;
Wed, 12 Mar 2014 13:04:35 -0700 (PDT)
Received: from tetra.site (nat-0-15.lam.cz. [80.92.242.254])
by mx.google.com with ESMTPSA id f45sm73660391eeg.5.2014.03.12.13.04.34
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 12 Mar 2014 13:04:34 -0700 (PDT)
Message-ID: <5320BDD1.50001@gk2.sk>
Date: Wed, 12 Mar 2014 21:04:33 +0100
From: Pavol Rusnak <stick@gk2.sk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: William Yager <will.yager@gmail.com>
References: <44fcb02b-3784-45a6-816a-312c78d940cd@me.com> <5320B7F1.8060701@gk2.sk>
<CAG8oi1M_jnn9vzHjN5h+0x-dYEKudgJ-DEqOKrdv-sCDaFV3NA@mail.gmail.com>
In-Reply-To: <CAG8oi1M_jnn9vzHjN5h+0x-dYEKudgJ-DEqOKrdv-sCDaFV3NA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WNpOM-0000f3-7t
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet
root key with optional encryption
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: Wed, 12 Mar 2014 20:04:44 -0000
On 03/12/2014 08:55 PM, William Yager wrote:
> The proposed BIP uses a bloom filter, so it has both plausible deniability *and
> *typo checking. The bloom filter is optimized for two elements and will
> catch something like 99.9975% of typos, despite allowing two different
> passwords.
Ok, I see. So the spec allows one real and one fake password. That is
something I don't consider plausible deniability. I am not saying that
this solution is wrong, I find it quite interesting, but it's not
plausible deniability. ;-)
>> I'm afraid one would end up with code generated in one client that is
>> unusable in a different client, because the client's developer thought
>> that using fancier algorithm instead of the proposed ones was a good idea.
>>
>>
> This is clearly in violation of the spec.
Ah, I misunderstood. I thought that outsourcing the KDF means allowing
the 3rd party to use any KDF instead of the specified ones. What would
be the reason to outsource if this is not possible, anyway?
--
Best Regards / S pozdravom,
Pavol Rusnak <stick@gk2.sk>
|
