Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions

From: Michael Gronager <[email-masked]>
Date: Wed, 13 Mar 2013 21:14:24 +0100

I hear consensus that at some point we need a hardfork (== 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. 

> 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 <=0.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