To: Tom Zander <tomz@freedommail.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPg+sBjdyJ297-GZvVc-wQwCEX-cRAGTNWDd92SgVzdCcD_ZMw@mail.gmail.com>
	<2034434.4WpKWoeOrB@strawberry>
	<03831fcd-1fd5-b769-0b3b-41e996894e1f@vt.edu>
	<7939356.11nSWPlGYM@strawberry>
From: Andrew C <achow101@gmail.com>
Message-ID: <22046ac7-df36-2e2a-759e-b3dd01601c59@gmail.com>
Date: Sun, 16 Oct 2016 17:19:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
	Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <7939356.11nSWPlGYM@strawberry>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Start time for BIP141 (segwit)
Precedence: list


On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote:
> Lets get back to the topic. Having a longer fallow period is a simple way to 
> be safe.  Your comments make me even more scared that safety is not taken 
> into account the way it would.

Can you please explain how having a longer grace period makes it any
safer? Once the fork reaches the LOCKED_IN status, the fork will become
active after the period is over. How does having a longer grace period
make this any safer besides just adding more waiting before it goes
active? You said something about rolling back the changes. There is no
mechanism for roll backs, and the whole point of the soft fork
signalling is such that there is no need to roll back anything because
miners have signaled that they are supporting the fork.