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
136
137
138
139
140
141
142
143
144
145
146
147
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SoJ0T-00039k-Kt
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 18:48:25 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SoJ0S-0004kJ-JB
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 18:48:25 +0000
Received: by pbbrq2 with SMTP id rq2so18586353pbb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Jul 2012 11:48:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.226.102 with SMTP id rr6mr62101759pbc.99.1341859698731;
Mon, 09 Jul 2012 11:48:18 -0700 (PDT)
Received: by 10.68.59.6 with HTTP; Mon, 9 Jul 2012 11:48:18 -0700 (PDT)
In-Reply-To: <1341857882.56956.YahooMailNeo@web121006.mail.ne1.yahoo.com>
References: <1341849295.94710.YahooMailNeo@web121003.mail.ne1.yahoo.com>
<CAAS2fgRd0gqrxXs4Le6nydYBaG7EO=T7FrtX6QZpg3aJtAxSvg@mail.gmail.com>
<1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com>
<CAAS2fgQRo4swDTQjPE0PmnpZ9uS+TDNQdOR6q4K70xsNJY9RfQ@mail.gmail.com>
<1341857882.56956.YahooMailNeo@web121006.mail.ne1.yahoo.com>
Date: Mon, 9 Jul 2012 14:48:18 -0400
Message-ID: <CAAS2fgTB-c+F9Fvcva-NyADSQgJih2VBEW_0bA5h1yYLowNH9Q@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.2 (-)
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.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SoJ0S-0004kJ-JB
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Random order for clients page
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 18:48:25 -0000
On Mon, Jul 9, 2012 at 2:18 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> The only thing that's changed between now and this morning is:
>
> - Addition of Bitcoin Wallet for Android
> - Randomisation of entries
Yes, because I reverted eight commits to it by you because they were
clearly controversial, including the proprietary clients section and
blockchain.info.
You went on to add the randomization, again without a pull request
and, as seen here, its somewhat controversial.
> I actually got permission from everyone involved before making the page.I=
f you want to remove the page, then we should see a vote by:
Luke originally authored the multiple clients page. It sounded like it
could be useful and I made some recommendations for it too. I'm
concerned that it's not working out that well. Thus "we should
probably consider". Perhaps that came off as too strong. If I really
pushing for that I'd submit it as a pull request. (and everyone,
including the people you listed, could comment)
I think the fact that we can just remove it if we can't agree on it is
a useful point to the discussion. For the site to be a neutral
resource it should be conservatively operated and if sometimes being
neutral, safe, and conservative gets in the way of being complete then
we should choose those other things over completeness. There are a
great many other resources available, bitcoin.org will never contain
all the relevant knowledge.
> You're proposing to remove the page.You know, and I know and I know that =
you know that nobody visits the Wiki.
Crazy. I have considerable evidence to the contrary, in fact. The wiki
is widely used and promoted as the primary community memory.
I certainly didn't agree with that suggestion because I thought it
wouldn't get seen. I found it agreeable because it would reflect the
lower degree of consensus we apparently have about listing the page.
> Have you tried the new clients? I've tried all 4, and they are all well w=
ritten.
I've used multibit, armory, and electrum (though not for some time). I
shed painted the electrum determinstic wallet stuff pretty extensively
when it was first created, and I think the wordlist seed stuff was my
suggestion.
> Try the new version of Electrum, https://gitorious.org/electrum/electrum =
- it's more featureful and secure than Bitcoin-Qt what with deterministic w=
allets, brain-wallets, prioritising addresses, frozen addresses, offline tr=
ansactions - none of which Bitcoin-Qt has.
I'd like to invite you to point your electrum client against a server
I operate. I will then happily agree with you that it is more secure:
because the bitcoin I rob from you will soothe my pain at the loss of
this "debate". Sound like a deal?
I think you're exaggerating the features there, and simultaneously
underplaying the fact that clients doesn't actually participate in the
bitcoin protocol, don't provide the security promises of bitcoin, and
basically leave us with a centralized system (if thats all we had).
It's a worthwhile part of the ecosystem, I agree.
> MultiBit is also very good with QR integration and the ability for mercha=
nts to quickly set themselves up. It's full of guiding help text, and has t=
his paradigm to allow people to work with keys.
There has been QR integration in bitcoin-qt for some time. ::shrugs::
I don't really understand why you're arguing features here: Yes the
other clients are great things. I never said they weren't. They are
not, however, complete alternatives to the reference client yet.
> There is absolutely no reason to remove this page unless you think bitcoi=
n.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jg=
arzik, and the long-term stated goal of bitcoin.org as a neutral resource f=
or the community.
Please stop putting words in my mouth. I certainly don't think that.
|
