Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.45 as permitted sender)
	client-ip=209.85.215.45; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f45.google.com; 
MIME-Version: 1.0
In-Reply-To: <201303131256.30144.luke@dashjr.org>
References: <201303131256.30144.luke@dashjr.org>
Date: Wed, 13 Mar 2013 06:14:00 -0700
Message-ID: <CAAS2fgRJxx3VwBoQm2Tkwr-DbAg6wQityzegZXxddXbqBSh8dQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.8.1 ideas
Precedence: list

On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr <luke@dashjr.org> wrote:
> FROM block 262144 to block 393216 (hard fork #1):
> - Never make, and reject any block that includes more than 24391 transaction
> modifications on its own (this *should* be equivalent to 1 MB)
> - (this rules can make older client backports safe unless a reorg is more than
> 6 blocks deep)

I'm not a fan of the two stages, your before block 262144 part sounds
fine to me, though I thought the safe number was closer to 5000.
Perhaps 4911?
The goal here is to pick something which is _absolutely sure_ to be
less than what pre-0.8 accepts (so that its is just a soft fork), but
it need not be needlessly smaller than that.

I think we can accept some small risk of "backport" clients getting
stuck after large reorgs after there has been sufficient upgrade time.
 Performance reasons mean that its very likely no one will be mining
on those nodes by then, and so if they get stuck they'll just need to
manually unstick them. Difficulty is high enough that its unlikely
anything important will remain stuck long enough for a malicious party
to exploit them by mining blocks on the stuck fork.

By allowing that risk you halve the complexity of your change by not
requiring two hard forks.  The 'never make' half of it would probably
be fine.

As far as the size change, that should be a separate process after
we've proven the ability to make a hardforking change with something
low risk/low controversy like this, and only after someone has
actually shown that the software is stable under those conditions lest
we get another issue like we have now where the increase in block
target from 500k/250k to 1MB by a miner exposed inadequate testing.