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; 
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>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Precedence: list

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