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-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SoEhM-0005Wg-Lu
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 14:12:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=gmaxwell@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SoEhH-0001S5-7V
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 14:12:24 +0000
Received: by pbbrq2 with SMTP id rq2so18237327pbb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Jul 2012 07:12:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.134.161 with SMTP id pl1mr48715980pbb.29.1341843133118;
Mon, 09 Jul 2012 07:12:13 -0700 (PDT)
Received: by 10.68.59.6 with HTTP; Mon, 9 Jul 2012 07:12:11 -0700 (PDT)
In-Reply-To: <CAAS2fgRZJW02_76G-vjV8V7kDy5WoxN1Ftd4baeBjyYVBcgJiA@mail.gmail.com>
References: <1341825681.35206.YahooMailNeo@web121001.mail.ne1.yahoo.com>
<CAAS2fgRZJW02_76G-vjV8V7kDy5WoxN1Ftd4baeBjyYVBcgJiA@mail.gmail.com>
Date: Mon, 9 Jul 2012 10:12:11 -0400
Message-ID: <CAAS2fgTtv6dEf7TKeK8ecm0ic+yfz-qXSWveKz-cxyGdQ4NwKw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.1 (-)
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.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SoEhH-0001S5-7V
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android
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, 09 Jul 2012 14:12:24 -0000
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote=
:
> I've reverted these additions to the page, nothing personal but=E2=80=94
Er, to be clear, I left the android software in because the source is
available (And I'm told its had some review).
I removed the proprietary software section the plug for the
blockchain.info webservices, and the demotion of the armory client.
As far as criteria goes, I don't think we should list anything with a
security model weaker than SPV unless users can practically operate
their own servers. =E2=80=A6and even that I'm a little uneasy with, because
most people will use the defaults. Ideally even thin clients would
have a near SPV security model, just without the bandwidth. But since
the alternative for thin clients is centralized web services the lower
standard will probably have better net results for now.
Nor do I think we should list anything which can't currently be
subjected to independent review of the whole stack (e.g. including the
server components in thinclients, unless the server is untrusted). In
the future this should be raised to there existing actual evidence of
third party review.
|
