MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 21 Dec 2015 11:58:50 +0800
From: joe2015@openmailbox.org
To: Jeff Garzik <jgarzik@gmail.com>
In-Reply-To: <CADm_WcYXU6VXG034j=mD8zkmqNLB96sjvBc6qo8Sx2NepHJk8A@mail.gmail.com>
References: <dcf6dfa0f7fdcf96e9970e815e4c9b78@openmailbox.org>
	<CADm_WcYXU6VXG034j=mD8zkmqNLB96sjvBc6qo8Sx2NepHJk8A@mail.gmail.com>
Message-ID: <489826397e6b36bf68391508952042f4@openmailbox.org>
User-Agent: Roundcube Webmail/1.0.6
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized)
 softfork.
Precedence: list

On 2015-12-21 11:39, Jeff Garzik wrote:
> On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Current hard fork implementations include / will include miner
> lock-in, just like any soft fork.  They will not activate if global
> consensus is not reached.

That's not true at all. They activate with a miner majority (e.g. 75%, 
95%, etc.), not global consensus.  Here global really means global, i.e. 
miner, economic, all clients, etc.  In the case of a hardfork there is 
nothing stopping the miner minority from continuing the old chain.  With 
a softfork the miner minority is forced to upgrade otherwise their 
blocks will be eventually orphaned.

My proposal achieves a hardfork-like blocksize limit increase but, like 
a softfork, also forces the miner minority to upgrade.

--joe.