MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <93708933-fdea-cdfc-20fc-b18040b98110@mattcorallo.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<93708933-fdea-cdfc-20fc-b18040b98110@mattcorallo.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Fri, 7 Jul 2017 23:25:32 +0000
Message-ID: <CAAS2fgSH8tugh3gBYmMY-ZEzO6c=jZoMczTi7ifULxP9xJsEpQ@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: text/plain; charset="UTF-8"
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
Precedence: list

On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This is not a hard fork, simply adding a new limit is a soft fork. You
> appear to be confused - as originally written, AFAIR, Jeff's btc1 branch
> did not increase the block size, your specification here matches that
> original change, and does not increase the block size.

Indeed, their code previously did not increase the blocksize but it
was adjusted at the last minute to do so-- so it may actually do that
now. Because they don't appear to have implemented any tests for it, I
wouldn't be too surprised if it still didn't work at all but also
wouldn't be surprised if it did.

You are correct that the specification text appears to refer to the
prior change that did not. (In my response I just assumed that it
meant what they actually did-- good catch).