MIME-Version: 1.0
In-Reply-To: <2c9dd1c02fc550438d4bbab29e052f34@xbt.hk>
References: <20150723162321.Horde.bphh__8AhyXa_m-YAYpiyw1@server47.web-hosting.com>
	<CAE-z3OWZGsSS2s1OZU5ScH7C4BcOtCb9mcz62TA7HZQe_=y0uA@mail.gmail.com>
	<20150723192633.Horde.cGMZGo9Ji0-_9HZhcSUpww5@server47.web-hosting.com>
	<CABFP+yNgzNBtsfgHMNSJKpJmgD8jK13KRFP_P9+50ekiBoHfmQ@mail.gmail.com>
	<2c9dd1c02fc550438d4bbab29e052f34@xbt.hk>
Date: Sun, 2 Aug 2015 06:53:20 -0400
Message-ID: <CABFP+yOd2ssjuBW3VQPYMCVepeVSMZp3C7w3-fkPW1pmGChAWA@mail.gmail.com>
From: Michael Ruddy <mruddybtc@gmail.com>
To: jl2012@xbt.hk
Content-Type: text/plain; charset=UTF-8
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP draft: Hardfork bit
Precedence: list

I think your "hardfork bit" proposal is clever.
It addresses the particular valid concern of re-org facing users of a
fork that a small/near/fluctuating majority, or less, of mining power
supported.
While the "economic majority" argument may be enough on its own in
that case, it still has some aspect of being a hand wave.
This proposal adds support to those economic actors, which makes it
easier for them to switch if/when they choose. That is, it provides a
good fallback mechanism that allows them to make a decision and say,
"we're doing this".
Do you have the latest version up on github, or someplace where it
would be easier to collaborate on the specific text?

On Sat, Aug 1, 2015 at 4:23 PM,  <jl2012@xbt.hk> wrote:
> Although the chance is very slim, it is possible to have multiple hardforks
> sharing the same flag block. For example, different proposals may decide the
> flag time based on voting result and 2 proposals may have the same flag time
> just by chance. The coinbase message is to preclude any potential ambiguity.
> It also provides additional info to warning system of non-upgrading nodes.
>
> If we are pretty sure that there won't be other hardfork proposal at the
> same time, the coinbase message may not be necessary. With some prior
> collaboration, this may also be avoided (e.g. no sharing flag block allowed
> as consensus rules of the hardforks)
>
> The "version 0" idea is not compatible with the version bits voting system,
> so I have this hardfork bit BIP after thinking more carefully. Otherwise
> they are technically similar.