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: <20130313174838.GA22621@savin>
Date: Wed, 13 Mar 2013 19:01:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com>
References: <CABsx9T0xOpNpFG4bo7wjcMV8a_xtw_jrRx_fiSutX08yfP8P7Q@mail.gmail.com>
	<20130313174838.GA22621@savin>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions
Precedence: list

Please note that it was not 0.8 that had issues, but 0.7(and downwards).

I really think changing features in 0.8 aiming for a fluffy limit to =
avoid lock object errors on 0.7 is the wrong way to go, and it will =
never cover for a similar situations in the future.

Instead I would like to propose a setup for "considerate mining":
* Run pools either on newest or second newest version (up to you =
depending on which features you like as a pool admin) - say e.g. 0.8
* Connect to the rest of the bitcoin network _only_ through a node of =
the other version - say e.g. 0.7

This guarantees that no blocks will get into the network that will not =
be accepted by both 0.8 and 0.7. Those two  versions together should add =
up to say >90%.

Once everyone else (90%) have upgraded to the newest, (0.8), drop the =
0.7 and start to introduce 0.9 instead.

/M