MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 21 Dec 2015 12:41:54 +0800
From: joe2015@openmailbox.org
To: jl2012 <jl2012@xbt.hk>
In-Reply-To: <e170f3a10164019824edaafe5a04f067@xbt.hk>
References: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org>
	<e170f3a10164019824edaafe5a04f067@xbt.hk>
Message-ID: <f9ad1348fb7dedca35b594782fee7e0f@openmailbox.org>
User-Agent: Roundcube Webmail/1.0.6
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized)
 softfork.
Precedence: list

On 2015-12-21 12:23, jl2012 wrote:
> I proposed something very similar 2 years ago:
> https://bitcointalk.org/index.php?topic=283746.0

Yes there are similarities but also some important differences.  See my 
response here: 
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012085.html

In short my proposal is compatible with conventional blocksize limit 
hardfork ideas, like BIP101, BIP202, 2-4-8 etc. etc.

> This is an interesting academic idea. But the way you implement it
> will immediately kill all existing full and SPV nodes (not really
> dead, rather like zombie as they can't send and receive any tx).

That's the whole point.  After a conventional hardfork everyone needs to 
upgrade, but there is no way to force users to upgrade.  A user who is 
simply unaware of the fork, or disagrees with the fork, uses the old 
client and the currency splits.

Under this proposal old clients effectively enter "zombie" mode, forcing 
users to upgrade.

--joe