Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Michael Gronager <gronager@ceptacle.com>
In-Reply-To: <CAAS2fgSOxon1m79gA_afgG7ypHRJfurb4ydZuCBgb_sSy1HG+w@mail.gmail.com>
Date: Tue, 12 Mar 2013 14:00:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F4490C7-8846-4AA7-AF9B-9A02DDEC6245@ceptacle.com>
References: <CAPg+sBip_4Jtxhq+rm-na2=RSJ_PuoZt+akGgJyo0b_Bwbr1Dw@mail.gmail.com>
	<CAPg+sBjm+e=A+edSRHXU7JSqyfSc4hou_SRdQHF48xhKQGA4zA@mail.gmail.com>
	<CANEZrP2V9uDQ-dmyaUBbsCuj5u3Mrh+jvU9RDpYkrKQV6+t0tQ@mail.gmail.com>
	<CAAS2fgSOxon1m79gA_afgG7ypHRJfurb4ydZuCBgb_sSy1HG+w@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Warning: many 0.7 nodes break on large
	number of tx/block; fork risk
Precedence: list

>> 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