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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1TLuJk-0003XN-Jd
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Oct 2012 11:19:12 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TLuJf-0003DV-3B
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Oct 2012 11:19:12 +0000
Received: by mail-wg0-f53.google.com with SMTP id dr1so280555wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Oct 2012 04:19:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.201.156 with SMTP id b28mr14257045weo.4.1349867940884;
Wed, 10 Oct 2012 04:19:00 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.236.30 with HTTP; Wed, 10 Oct 2012 04:19:00 -0700 (PDT)
In-Reply-To: <CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com>
References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
<CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
<CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com>
Date: Wed, 10 Oct 2012 13:19:00 +0200
X-Google-Sender-Auth: Bwirub5s68h7n39qirUQ0CTTG7s
Message-ID: <CANEZrP3u7Nyq0qZDxwgdOmqM=OqVmAYaj-YBDFwY6Ps-XTc46A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1TLuJf-0003DV-3B
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 11:19:12 -0000
+gary
> Electrum also has a daemon for merchants.
Well, I suggest taking it up with Thomas directly. A thread here won't do m=
uch.
> Considering the dislike of
> Java that exist reflexively in much of the non-java community and the
> greater ease of deployment and the integration of type-2 split key
> management
I'm hoping that MultiBit Merchant will provide something similar based
on bcj, ie, you don't have to actually be a Java developer to use it,
it can just talk to your app via POSTs and GETs.
WRT deterministic wallets, yes, right now that's indeed a competitive
advantage of Electrum. So much code to write, so little time.
> Generally for thin clients=E2=80=94 a lying server can make clients think
> they've received confirmed payments they haven't, and unless the
> client is constructed to be a bit less thin a lying server can lie
> about input values and cause thin clients to spend large values to
> fees.
Yes indeed. This also gives [hacked] server operators a way to steal
money from users without private keys, they can get clients to create
some very high fee transactions and then provide them directly to a
miner who promises to cut them in (or they can mine themselves, of
course).
> Beyond that the protocol between the clients and servers is
> unauthenticated cleartext JSON in TCP.
I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar appr=
oach.
> that the payment is unconfirmed. There is a "pro" mode, that shows
> 'processing' for unconfirmed transactions
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
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.
> My only question is will they know this because we as a community and
> the authors of the thin clients provided clear explanations and
> appropriate caution
Well, I pushed for English-text explanations of clients on bitcoin.org
rather than a feature matrix, for this kind of reason :) Unfortunately
the current texts are too small to really give a detailed explanation
of the security models involved. It may be worth adding one-liners
that link to a page explaining different security models (full, SPV,
superlight).
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.
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
the wiki would be good. And a simple "Welcome to Bitcoin" flow on the
bitcoin.org website that guides people to appropriate clients, teaches
them the security basics, etc, would be excellent.
|
