Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrMFj-00073L-1v for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 03:48:15 +0000 X-ACL-Warn: Received: from mail-iy0-f171.google.com ([209.85.210.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QrMFh-0003Pt-T1 for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 03:48:14 +0000 Received: by iyf13 with SMTP id 13so486158iyf.30 for ; Wed, 10 Aug 2011 20:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.91.139 with SMTP id p11mr7602851icm.402.1313032825910; Wed, 10 Aug 2011 20:20:25 -0700 (PDT) Received: by 10.42.226.4 with HTTP; Wed, 10 Aug 2011 20:20:25 -0700 (PDT) X-Originating-IP: [99.173.148.118] In-Reply-To: <201108102338.21680.andyparkins@gmail.com> References: <201108102213.09632.andyparkins@gmail.com> <201108102338.21680.andyparkins@gmail.com> Date: Wed, 10 Aug 2011 23:20:25 -0400 Message-ID: From: Jeff Garzik To: Andy Parkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1QrMFh-0003Pt-T1 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 03:48:15 -0000 On Wed, Aug 10, 2011 at 6:38 PM, Andy Parkins wrote= : > On Wednesday 10 August 2011 22:35:01 Jeff Garzik wrote: > >> On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins > wrote: >> > Don't believe me? =A0Here'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. >> > =A0Only some of which would break backward compatibility. >> >> Breaking backwards compatibility means breaking people's access to >> their own money. > > I wasn't actually giving a full explanation of how these things could be > done, I was providing a list of "negatively received ideas"; imagine my > surprise that they have been negatively received by you. > > However... The version number field combined with the massive complexity = of: > > =A0if( blockNumber > 500000 ) > =A0 new_process(); > =A0else > =A0 old_process(); > > Would sort all of your "compatibility" objections out, and would give nod= es > 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 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. 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. > However, the protocol is being treated as if it is some kind of holy scro= ll, > and must not be touched. Bitcoin's ideas are revolutionary, its > implementation is not. If we started again today, it would be done > differently. Shouldn't we be trying to move the current protocol toward > _that_ "done differently" as much as possible while bitcoin is still > relatively small? Rhetorical again... I know the answer, it's "no". 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. 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... > I disagree about how set in stone these things are; but yeah; I've accept= ed > that I'm on a loser. =A0My list was to demonstrate how negative the commu= nity > is; and you have confirmed that for me admirably. =A0Bear that in mind th= e > next time you're discussing the lack of manpower for bug fixes. It's negative to weight costs vs. benefits? That is what I expect any good engineer to do. 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. 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. --=20 Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com