From: <jl2012@xbt.hk>
To: "'Matt Corallo'" <lf-lists@mattcorallo.com>,
	<bitcoin-dev@lists.linuxfoundation.org>
References: <239b01d16344$717712d0$54653870$@xbt.hk>
	<56BA64F3.2060900@mattcorallo.com>
In-Reply-To: <56BA64F3.2060900@mattcorallo.com>
Date: Wed, 10 Feb 2016 12:26:03 +0800
Message-ID: <23ab01d163bb$28e140a0$7aa3c1e0$@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AQHGHiFSfOL5uUJrxN+FpKFqqUC6GQE+7KHLnzFAe8A=
Content-Language: en-hk
Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger
	block size
Precedence: list

I am actually suggesting 1 hardfork, not 2. However, different rules are
activated at different time to enhance safety and reduce disruption. The
advantage is people are required to upgrade once, not twice. Any clients
designed for stage 2 should also be ready for stage 3.


-----Original Message-----
From: Matt Corallo [mailto:lf-lists@mattcorallo.com] 
Sent: Wednesday, 10 February, 2016 06:15
To: jl2012@xbt.hk; bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger
block size

As for your stages idea, I generally like the idea (and mentioned it may be
a good idea in my proposal), but am worried about scheduling two hard-forks
at once....Lets do our first hard-fork first with the things we think we
will need anytime in the visible future that we have reasonable designs for
now, and talk about a second one after we've seen what did/didnt blow up
with the first one.

Anyway, this generally seems reasonable - it looks like most of this matches
up with what I said more specifically in my mail yesterday, with the
addition of timewarp fixes, which we should probably add, and Luke's header
changes, which I need to spend some more time thinking about.

Matt