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
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QrG5Z-0007BK-Re
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 21:13:21 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47; envelope-from=andyparkins@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrG5Y-0000af-Rl
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 21:13:21 +0000
Received: by fxg11 with SMTP id 11so2093584fxg.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Aug 2011 14:13:14 -0700 (PDT)
Received: by 10.223.102.68 with SMTP id f4mr1775912fao.117.1313010794581;
Wed, 10 Aug 2011 14:13:14 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id c5sm67612fah.30.2011.08.10.14.13.12
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 10 Aug 2011 14:13:13 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Date: Wed, 10 Aug 2011 22:13:09 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<201108102032.00373.andyparkins@gmail.com>
<CA+8xBpdCtYQkKwQZzZY2PsHm=+BrhD4TdoKqoAVoa7R0W9YkRw@mail.gmail.com>
In-Reply-To: <CA+8xBpdCtYQkKwQZzZY2PsHm=+BrhD4TdoKqoAVoa7R0W9YkRw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108102213.09632.andyparkins@gmail.com>
X-Spam-Score: -1.6 (-)
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
(andyparkins[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 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QrG5Y-0000af-Rl
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
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 Aug 2011 21:13:21 -0000
On Wednesday 10 August 2011 20:57:29 Jeff Garzik wrote:
> > People get itches and they want to scratch them. They aren't paid, so
> > they don't necessarilly want to turn up and be told which part they
> > _should_ be working on. The choice is not "bug fix that Gavin wants"
> > or "new feature that New Developer wants", it is "New Feature" or
> > nothing.
>
> This is true -- though there is value to having a list of "things we
> think people should focus on" for the motivated, and for new people
> interested in tackling a project, but not sure what project to tackle.
My objection is not that such a list exists, it is that potential new
developers are, essentially, shouted down unless they are working on that
list. I cannot imagine that many new developers arrive under those
circumstances.
> A centrally managed development branch on bitcoin/bitcoin.git is not
> the way to do it, however. See the description of linux-next, in my
> previous email, for a more distributed method which can easily be
> layered on top of the existing bitcoin dev structure by any motivated
> volunteer(s).
I don't think I said anything about it being centrally managed. git lets us
store these branches anywhere of course. The fact is that such a branch
exists somewhere.
> Think distributed. :) The community does not need Linus's help
> (linux-next) or Gavin's help (bitcoin-next) to do this. linux-next
I didn't say that it required anybody's help; but it does require a bit of
willingess on the part of the master-branch-owning developers to import from
that branch.
> became so widely used and useful that Linus requires almost all
> changes to be first staged in linux-next.
They key thing with linux-next is that work done on it _does_ make it into
the kernel. Tell me -- how many feature branches for bitcoin are just
sitting as a pull request on github, and are now months old and abandoned
out of disgust by their original authors? Here's another question: why is
it that so many projects have "specially compiled" versions of bitcoin?
Rhetorical question... it's because the official client doesn't do what they
need, and won't accept their patches to add it (even optionally).
I've only been watching this list for a few weeks (since the forum turned
into an echo chamber); but I'm completely depressed by the agressive
rejections of every new idea anyone raises.
Don't believe me? Here's a list of ideas I've had "no, no, no"d so far; not
one of which would have any financial implication at all. Only some of
which would break backward compatibility.
- Extra bits in the service field of the version message to allow nodes
to indicate if they are mining; if they are willing to be seed nodes;
if they relay transactions; if they want relayed transactions.
- getblocks in reverse chronological order so clients can start up quicker
while downloading the blocks in the backround. Ironically I was told
"patches welcome" by someone who didn't reject this one instantly.
- Remove verack, as it's completely unnecessary.
- Query miners for pending transactions
- Application version separate from client version
- A way of requesting block bodies without headers (saving a lot of traffic
for a thin client upgrading)
- Double SHA-256 for a packet checksum? Seriously?
- Sequence number as part of TxIn instead of part of the whole transaction
- Script parameters should be stored outside the script, and reference by
the script. All that ridiculous filtering of the scripts in OP_CHECKSIG
would then go away.
- MSG_DOUBLESPEND... nope
- getblocks to accept MSG_TX and do something sensible
Every single one of those has been shot down by one or more of the main
developers. I'm not a genius, and not arrogant enough to assume that
everything I say is right, but _nothing_? Really? There is no problem that
one of the above addresses?
Given that, what do I do? Hang around and get battered some more, or go
away to my own little corner and work on my own implementation?
You can imagine then that when I read moans about there not being enough new
developers fixing bugs, that I am unsurprised and unsympathetic. I like
bitcoin enough to hover on this list; and offer a view of your world from a
potential developer who was chased away.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
