From: Rusty Russell <rusty@rustcorp.com.au>
To: Tom Harding <tomh@thinlink.com>, bitcoin-dev@lists.linuxfoundation.org
In-Reply-To: <5602F075.4000102@thinlink.com>
References: <87mvwqb132.fsf@rustcorp.com.au> <5602F075.4000102@thinlink.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Wed, 30 Sep 2015 11:35:47 +0930
Message-ID: <8737xwhdac.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and
	delay.
Precedence: list

Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
>> '''Success: Activation Delay'''
>> The consensus rules related to ''locked-in'' soft fork will be enforced in
>> the second retarget period; ie. there is a one retarget period in
>> which the remaining 5% can upgrade.  At the that activation block and
>> after, the bit B may be reused for a different soft fork.
>>
>
> Rather than a simple one-period delay, should there be a one-period 
> "burn-in" to show sustained support of the threshold?  During this 
> period, support must continuously remain above the threshold.  Any lapse 
> resets to inactivated state.
>
> With a simple delay, you can have the embarrassing situation where 
> support falls off during the delay period and there is far below 
> threshold support just moments prior to enforcement, but enforcement 
> happens anyway.

Yeah, but Gavin's right.  If you can't account for all the corner cases,
all you can do is keep it simple and well defined.

Thanks,
Rusty.