Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrODn-0007Di-Qt for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 05:54:23 +0000 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; Received: from mail-wy0-f175.google.com ([74.125.82.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QrODm-0000Dx-Rz for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 05:54:23 +0000 Received: by wyf19 with SMTP id 19so1821632wyf.34 for ; Wed, 10 Aug 2011 22:54:16 -0700 (PDT) Received: by 10.216.169.207 with SMTP id n57mr1442691wel.37.1313041659028; Wed, 10 Aug 2011 22:47:39 -0700 (PDT) Received: from grissom.localnet ([91.84.15.31]) by mx.google.com with ESMTPS id et16sm1281327wbb.19.2011.08.10.22.47.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Aug 2011 22:47:37 -0700 (PDT) From: Andy Parkins To: Jeff Garzik 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: <201108102338.21680.andyparkins@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108110647.35194.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: 1QrODm-0000Dx-Rz 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 05:54:23 -0000 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