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: <20130313182805.GA7921@vps7135.xlshosting.net>
Date: Wed, 13 Mar 2013 21:14:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BEB68029-123A-4497-A59B-6487FE99742B@ceptacle.com>
References: <CABsx9T0xOpNpFG4bo7wjcMV8a_xtw_jrRx_fiSutX08yfP8P7Q@mail.gmail.com>
	<20130313174838.GA22621@savin>
	<2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com>
	<20130313182805.GA7921@vps7135.xlshosting.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net,
	Michael Gronager <gronager@ceptacle.com>
Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions
Precedence: list

I hear consensus that at some point we need a hardfork (=3D=3D creating =
blocks that will not be accepted by <0.7 clients).

Miners generate block, hence they are the ones who should filter =
themselves though some consensus.=20


> But we cannot just drop support for old nodes. It is completely =
unreasonable to put the
> _majority_ of the network on a fork, without even as much as a =
discussion about it.
> "Oh, you didn't get the memo? The rules implemented in your client are =
outdated." - that
> is not how Bitcoin works: the network defines the rules.

Consensus was rapidly reached a day ago: To ensure the majority (all =
of?) the network could accept the blocks mined, and not just 0.8. This =
was the right decision! Too many was dependent on <=3D0.7

So, the question is not if, but when to do a hardfork. We need to define =
and monitor the % of nodes running different versions (preferably a =
weighted average - some nodes, like e.g. blockchain.info & mtgox serve =
many...). Once there was the rowit bitcoinstatus page - do we have =
another resource for this ?

Then the second question is how to ensure we don't create a fork again? =
Pieter (and others?) are of the opinion that we should mimic a 0.7 =
lock-object-starvation-reject-rule. I don't like this for three reasons:
1. I find it hard to ensure we have actually coined the bug precisely
2. I expect that similar issues will happen again
3. The current issue was between two versions, but in the future it =
could be between two implementations - then trying implement or even to =
coordinate strange rules becomes very unlikely.

Hence the scheme for "considerate mining" - it is the only scheme that =
guarantees 100% that no block are released that will not be accepted by =
a supermajority of the install base.

Another nice thing about it - it requires no development :)

So simply run in serial in front of all considerate miners nodes of =
different versions until a certain threshold of the install base is =
reached.

/M