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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1TLy8H-00070r-10
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Oct 2012 15:23:37 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.175 as permitted sender)
client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f175.google.com;
Received: from mail-ie0-f175.google.com ([209.85.223.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TLy8D-0000sE-6I
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Oct 2012 15:23:37 +0000
Received: by mail-ie0-f175.google.com with SMTP id c13so1129776ieb.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Oct 2012 08:23:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.236.74 with SMTP id us10mr5738603igc.5.1349882605978; Wed,
10 Oct 2012 08:23:25 -0700 (PDT)
Received: by 10.64.34.4 with HTTP; Wed, 10 Oct 2012 08:23:25 -0700 (PDT)
In-Reply-To: <CANEZrP3u7Nyq0qZDxwgdOmqM=OqVmAYaj-YBDFwY6Ps-XTc46A@mail.gmail.com>
References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
<CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
<CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com>
<CANEZrP3u7Nyq0qZDxwgdOmqM=OqVmAYaj-YBDFwY6Ps-XTc46A@mail.gmail.com>
Date: Wed, 10 Oct 2012 11:23:25 -0400
Message-ID: <CAAS2fgSkVRx3Tk-7ufMDb3a44eTK=6COOh_FBWqrmwH4ogFhgA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.4 (-)
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.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information 0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TLy8D-0000sE-6I
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
electrum.desktop@gmail.com
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: Wed, 10 Oct 2012 15:23:37 -0000
On Wed, Oct 10, 2012 at 7:19 AM, Mike Hearn <mike@plan99.net> wrote:
> +gary
>
>> Electrum also has a daemon for merchants.
>
> Well, I suggest taking it up with Thomas directly. A thread here won't do=
much.
I tried in IRC and got no response. These messages are copying the
only contact email address I could find.
> I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar ap=
proach.
Yes, so do a lot of people. It doesn't.
> I think communicating transaction confidence to users is something of
> an open UI design problem right now. I agree that hiding it entirely
> seems suboptimal, but in reality explaining what the risks are for a
There is a middle ground: You can not hide it without explaining it.
AFAICT we don't see ~any questions about the reference client waiting
for six confirmations before saying confirmed.
> given number confirmations is difficult. Given the lack of actually
> reported double-spends against unconfirmed transactions, I can
> understand this choice, even if I wouldn't recommend it.
There have been a great many circulated on the network. People don't
report all losses=E2=80=94 e.g. we've never seen a report from those who've
burned hundreds of bitcoins in fees on transactions.
> of the security models involved. It may be worth adding one-liners
> that link to a page explaining different security models (full, SPV,
> superlight).
Perhaps.
> One thing I'm really hoping we can find and get agreement on is
> somebody clueful and trustworthy to work on the bitcoin.org website.
I think this is very hard because this matter is rapidly politicized.
There are some in the community who will instantly allege misconduct
when there is a mis-agreement.
Basically: No one sane should want the job, and anyone who wants
should on no account be allowed to have it.
At this point I think we also will get better results communicating
among technical people in order to get the development focus adjusted
in a way that mitigates those risks that can be mitigated and those
cautions that can be offered offered.
After all, if the Electrum project is _unwilling_ to disclose the
limitations of their implementation and security model on their own
site, even after having them pointed out then someone updating
Bitcoin.org to include them will be politically contentious. I want
to make sure that we've followed all reasonable avenues before going
that route=E2=80=94 first I attempted informally on IRC, now I've brought t=
he
discussion here... instead of, e.g. starting the process to remove it
from the bitcoin.org clients page.
> Bitcoin, the project, needs a stronger voice than it currently has,
> partly to speak about such issues. For instance, an FAQ that isn't on
I agree, thats why I started this thread.
|
