Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.47 as permitted sender)
	client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
	helo=mail-qw0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <201110030132.21646.luke@dashjr.org>
References: <CAAS2fgRSw8ry7wjL5Fao1U+Ps0-6hfDcme_V_OCSkKaRTm2r9w@mail.gmail.com>
	<201110030132.21646.luke@dashjr.org>
Date: Mon, 3 Oct 2011 01:39:07 -0400
Message-ID: <CAAS2fgSgH5eH+9eY8e=T946NRW10_aiWvDM523+HJgBL2zEgew@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Supermajority mining votes for
 valid->invalid changes.
Precedence: list

On Mon, Oct 3, 2011 at 1:32 AM, Luke-Jr <luke@dashjr.org> wrote:
> Perhaps as a safeguard:
> (3) Before applying the new rule, require 50% of the last Y blocks contai=
n a
> =C2=A0 =C2=A0coinbase with a "I am upgraded" code
> (4) Until the new rule is active, include an "I am upgraded" code in ever=
y
> =C2=A0 =C2=A0block; after it's active, this can be turned off

(4) is a nice idea.

I was hoping to avoid (3) simply because for any one of these upgrades
hopefully 95% of the network is neutral wrt the change because they
won't mine either form of the transactions.

The active statement has the benefit that it constitutes a proof: You
know with specific confidence (based on the window size) how likely a
fork of length X will be if a newly invalid transaction is announced
at the time of the activation.