From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFOoc-0001cf-QZ for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 13:00:26 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UFOoa-0004S1-EN for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 13:00:26 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id B0B362B867D8; Tue, 12 Mar 2013 14:00:18 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzLjqGBSALZS; Tue, 12 Mar 2013 14:00:18 +0100 (CET) Received: from [109.105.106.206] (unknown [109.105.106.206]) by mail.ceptacle.com (Postfix) with ESMTPSA id C9DFF2B867C2; Tue, 12 Mar 2013 14:00:17 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Gronager In-Reply-To: Date: Tue, 12 Mar 2013 14:00:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F4490C7-8846-4AA7-AF9B-9A02DDEC6245@ceptacle.com> References: To: Gregory Maxwell X-Mailer: Apple Mail (2.1499) 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: 1UFOoa-0004S1-EN Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk 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: Tue, 12 Mar 2013 13:00:27 -0000 >> Forks are caused by rejection criteria, hence: >> 1. If you introduce new rejection criteria in an upgrade miners = should upgrade _first_. >> 2. If you loosen some rejection criteria miners should upgrade = _last_. >> 3. If you keep the same criteria assume 2. >=20 > And ... if you aren't aware that you're making a change ??? then only half should upgrade :-P Well I thought I covered that by 3... But, question is of course if we = could have been in a situation where 0.8 had been the one rejecting = blocks?=20 So miners could go with a filtering approach: only connect to the = network through a node of a version one less than the current. That = would still have caused block 225430 to be created, but it would never = have been relayed and hence no harm. (and if the issue had been in 0.8 = the block would not even have been accepted there in the first place). = Downside is some lost seconds. /M