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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1TZ97U-0006B9-VQ
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Nov 2012 23:45:17 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.175 as permitted sender)
client-ip=209.85.210.175; envelope-from=gmaxwell@gmail.com;
helo=mail-ia0-f175.google.com;
Received: from mail-ia0-f175.google.com ([209.85.210.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TZ97S-0005iJ-OO
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Nov 2012 23:45:16 +0000
Received: by mail-ia0-f175.google.com with SMTP id z3so1361317iad.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Nov 2012 15:45:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.178.8 with SMTP id cu8mr1642299igc.5.1353023109490; Thu, 15
Nov 2012 15:45:09 -0800 (PST)
Received: by 10.64.171.73 with HTTP; Thu, 15 Nov 2012 15:45:09 -0800 (PST)
In-Reply-To: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
Date: Thu, 15 Nov 2012 18:45:09 -0500
Message-ID: <CAAS2fgQWpkJZ26qx6_2ECVg3qGFw7H5Nx9L0ow0bboD6PWV4Lg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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
(gmaxwell[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
0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TZ97S-0005iJ-OO
Subject: Re: [Bitcoin-development] Electrum security model concerns
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, 15 Nov 2012 23:45:17 -0000
On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote=
:
> I'm concerned about how the particular security model of electrum is
> being described; or rather=E2=80=94 not being described.
Just to close the loop on this: I finally got in touch with Thomas on
IRC and walked over the security issues I brought up here, plus a
number of other ones.
He took the concerns seriously and rapidly redesigned big swaths of
electrum to eliminate the issues structurally. Electrum no longer a
classical thin client it is now a slightly watered down
simplified-payment-validation node with generally the same security
properties as other SPV nodes. Its network behavior leaves it somewhat
more vulnerable to isolation and compromise by a high hash power
attacker, because it does not (yet) make an effort to make sure it's
really on the longest chain. It is also more vulnerable to transaction
hiding (a DOS attack) for similar reasons. But this is still a
massive improvement. The UI was also changed and the confirmation
status of payments is no longer hidden.
There are still things to improve=E2=80=94 both in the client and the secur=
ity
communication to users. But I wanted to leave a note that it's come a
long way and that I now feel confident that any remaining issues will
be resolved.
|
