Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
	helo=mail-wy0-f175.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Date: Thu, 11 Aug 2011 06:47:34 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
	<201108102338.21680.andyparkins@gmail.com>
	<CA+8xBpdFH0YtkKPP6hKCf3Q2+2+Lzy0hjjaGYt6y8iBDudJuDw@mail.gmail.com>
In-Reply-To: <CA+8xBpdFH0YtkKPP6hKCf3Q2+2+Lzy0hjjaGYt6y8iBDudJuDw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108110647.35194.andyparkins@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Precedence: list

On Thursday 11 August 2011 04:20:25 Jeff Garzik wrote:

> > However... The version number field combined with the massive
> > complexity of:
> > 
> >  if( blockNumber > 500000 )
> >   new_process();
> >  else
> >   old_process();
> > 
> > Would sort all of your "compatibility" objections out, and would give
> > nodes time to upgrade.
> 
> The above has been discussed on the forums.  The community seems to
> consider that option one of last resort, because the consequences of
> -not- upgrading immediately become "I cannot access my money."  The

Did you even read what I wrote?  "if( blockNumber > 5000000 )" is about as 
far from immediate as you can get.  I'm not an idiot; I understand we can't 
lock people out of their money simply because of a software upgrade.  It's 
not unreasonable to expect people will have upgraded by block 500000 though 
(or whatever number the community decided upon).

Again you're missing my point... you are still shooting ideas down.

> community also seems rather hard-wired against breaking changes like
> that, because it implies that we lowly dev peons are daring to mess
> with the Blessed Satoshi Design that has received extensive study, and
> 100% communal agreement.

Well the community had better unhardwire itself or its going to end up with 
five developers and no more.

> If the community changes its mind, and there are strong calls to make
> a breaking change, we can certainly do that.  Bitcoin is not only open
> source but very much democratic -- people vote by choosing which
> client software to use.

Voting with ones feet should be a last resort.  Wouldn't it be better not to 
end up with incompatible clients out there?

> Historically speaking, the protocol has had minor tweaks, if you check
> the patch history.  Adding new protocol commands is pretty easy, for
> example.  Removing commands tends to be high cost for low benefit
> ("protocol removes a harmless redundancy"), if you're messing with the
> initial negotiation sequence.  IMO verack is not redundant, anyway.

Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am willing to lower to version 5 so I shall continue

or

Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am unwilling to lower to version 5 so I shall hang up

or

Client: I speak version 5
Server: hmmm, I speak version 10, but I am willing to speak version 5

or

Client: I speak version 5
Server: hmmm, I speak version 10, and I am unwilling to speak version 5
        so I shall hang up

'verack' is redundant.  It sends no information and merely says that the 
other end is willing to continue.  Willing to continue is easily determined 
when the remote continues.  Handling 'verack' is an annoyance, and adds 
nothing.

> But the answer is "what do the users want" not "no"  At the end of the
> day we're here to adequately reflect the needs of our userbase at all.
>  And so far, the userbase seems highly conservative when it comes to
> incompatible changes.  Correct me if I'm wrong...

Please point me at a single incompatible change that has been rejected by 
the userbase.

Further: I'm not suggesting incompatible changes alone; that would be 
insane.  I'm suggesting upgrade paths that delay incompatible changes until 
the change has propagated.

> It's negative to weight costs vs. benefits?  That is what I expect any
> good engineer to do.

I don't think that's what's happening.  Not once have I seen the "benefits" 
side of that equation.  What I have seen is plenty of "I can't see a use 
case for that"; when the key word in that sentence is "I".

> In any case, our -users- are not clamoring for breaking changes of the
> type you describe above, as far as I can see.  Just the opposite.  So
> if you want to deploy a breaking change, the burden is on you to
> convince the bitcoin users and miners that it's a good idea.

The users aren't typically going to be familiar enough with the internals of 
bitcoin to care about many of the changes I suggested.  I have repeatedly 
said I don't want to break anything, I want to transition in an orderly 
fashion (and the majority of my suggestions were backward compatible).  But 
of course, I don't actually want to do anything with bitcoind itself, it's 
been made repeatedly clear to me that anything I might ask for is not going 
to happen -- and of course what I was pointing out, _not_ asking for, was 
that you can't expect to get new developers on board if they aren't going to 
be allowed to scratch their itches.

> If the bitcoin dev team is not accurately reflecting the desire of its
> users, then that should be corrected, and we want to hear feedback.

You've just had some.  The response was "you're wrong".


Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com