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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1TLBsv-0001rP-H9
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Oct 2012 11:52:33 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TLBsu-0005F5-Ds
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Oct 2012 11:52:33 +0000
Received: by mail-wi0-f175.google.com with SMTP id hq4so2703967wib.10
for <bitcoin-development@lists.sourceforge.net>;
Mon, 08 Oct 2012 04:52:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.201.156 with SMTP id b28mr10046845weo.4.1349697146131;
Mon, 08 Oct 2012 04:52:26 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.236.30 with HTTP; Mon, 8 Oct 2012 04:52:26 -0700 (PDT)
In-Reply-To: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
Date: Mon, 8 Oct 2012 13:52:26 +0200
X-Google-Sender-Auth: ZGyI3_xBIAhwOV6d26RAjfLNUYk
Message-ID: <CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8
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: 1TLBsu-0005F5-Ds
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: Mon, 08 Oct 2012 11:52:33 -0000
> What I would expect is a proper discussion, like "Understanding the
> bitcoinj security model":
> http://code.google.com/p/bitcoinj/wiki/SecurityModel
That page was old, it stated that pending transactions aren't provided
to the app which hasn't been true for a long time.
I've rewritten and extended it. You may still not like what it says ;)
but it should at least be more thorough now. It also links to the ETH
paper.
Re: Electrum. In fairness the electrum page is designed for end users
and the bitcoinj page is designed for app developers. As far as I
know, there are no bitcoinj based clients that try to explain
transaction confidence to end users.
I don't think it's worth worrying about this too much right now. In
future the software end users and merchants use will diverge
significantly. At that time it'll be easier to tailor the
documentation to each user demographic. And I think Electrum type
services will go away once we do more optimizations like bloom
filtering and better peer selection logic, as the speed of SPV clients
will be comparable to Electrum/BCCAPI type clients but without the
need for a specific server operator.
|
