From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFqZM-0000oV-OE for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 18:38:32 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UFqZL-0005hU-UO for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 18:38:32 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id A3CD133C896; Wed, 13 Mar 2013 19:38:25 +0100 (CET) Date: Wed, 13 Mar 2013 19:38:25 +0100 From: Pieter Wuille To: Mark Friedenbach Message-ID: <20130313183824.GB7921@vps7135.xlshosting.net> References: <201303131256.30144.luke@dashjr.org> <20130313175825.GA21242@vps7135.xlshosting.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -1.2 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1UFqZL-0005hU-UO Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] 0.8.1 ideas 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: Wed, 13 Mar 2013 18:38:32 -0000 On Wed, Mar 13, 2013 at 11:27:13AM -0700, Mark Friedenbach wrote: > I know there's people here who will jump in saying that the bitcoin > protocol is the behavior of the Satoshi client, period. But which Satoshi > client? 0.7 or 0.8? The protocol is whatever the network enforces - and that is some mix of versions of the reference client right now, but doesn't need to remain that way. I would very much like to have a text book of rules that is authorative, and every client that follows it would be correct. Unfortunately, that is not how a consensus system works. All (full) clients validate all rules, and all must independently come to the same solution. Consensus is of utmost importance, more than some theoretical "correctness". If we'd have a specification document, and it was discovered that a lot of nodes on the network were doing something different than the document, those nodes would be buggy, but it would be the specification that is wrong. That is what happened: 0.7 and before had a bug, but 0.8 was wrong for not following the rules of the network (which I hate to say, as I'm responsible for many changes in 0.8). As said in another thread, the problem in the old versions needs fixing (this would even be the case if no 0.8 existed at all, and no fork risk existed at all). But let's please do it in a way we can all agree about, in a controlled fashion. -- Pieter