From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFs8H-0007J6-0h for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 20:18:41 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UFs8F-0007Z4-Q4 for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 20:18:40 +0000 Received: from ishibashi.localnet (unknown [173.170.142.26]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id D546327A2968; Wed, 13 Mar 2013 20:18:33 +0000 (UTC) From: "Luke-Jr" To: Mark Friedenbach Date: Wed, 13 Mar 2013 20:18:23 +0000 User-Agent: KMail/1.13.7 (Linux/3.7.3-gentoo; KDE/4.9.5; x86_64; ; ) References: <201303131256.30144.luke@dashjr.org> <20130313175825.GA21242@vps7135.xlshosting.net> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303132018.24649.luke@dashjr.org> X-Spam-Score: -2.4 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UFs8F-0007Z4-Q4 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 20:18:41 -0000 On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote: > Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules > which all verifying implementations must adhere to. I'm suggesting that we > instead change the old codebase to do what we expected it to do all along > (what 0.8 does and what every other verifying implementation does), and > through miner collusion buy ourselves enough time for people to update > their own installations. Curiously enough, at least MtGox's custom implementation stuck with the canonical blockchain despite 0.8's accidental rule change. > 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? How do you resolve that without being arbitrary? And > regardless, we are moving very quickly towards a multi-client future. This > problem is very clearly a *bug* in the old codebase. So let's be forward > thinking and do what we would do in any other situation: fix the bug, > responsibly notify people and give them time to react, then move on. Let's > not codify the bug in the protocol. No, if any other client released diverged from the consensus of all past/existing clients, we would do the same thing: call it a formerly unknown protocol rule, that this new client has a bug implementing, and be done with it. The only reason this particular issue needs special treatment is because the implications of the new rule mean that we're up against a hard limit in the protocol today rather than 2 years from now. Luke