MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 04 Feb 2016 12:56:42 -0500
From: jl2012 <jl2012@xbt.hk>
To: Gavin Andresen <gavinandresen@gmail.com>
In-Reply-To: <CABsx9T2VoWm04i_vQv7u0vXM6hdMBM29bnMSuv8RmMFMGxOdpg@mail.gmail.com>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
	<CABsx9T2VoWm04i_vQv7u0vXM6hdMBM29bnMSuv8RmMFMGxOdpg@mail.gmail.com>
Message-ID: <a4a8c42d8e6528dd7c0ae100958dd988@xbt.hk>
User-Agent: Roundcube Webmail/1.0.6
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
Precedence: list

Gavin Andresen 於 2016-02-04 12:36 寫到:
> This BIP is unnecessary, in my opinion.
> 
> I'm going to take issue with items (2) and (3) that are the motivation
> for this BIP:
> 
> " 2. Full nodes and SPV nodes following original consensus rules may
> not be aware of the deployment of a hardfork. They may stick to an
> economic-minority fork and unknowingly accept devalued legacy tokens."
> 
> If a hardfork is deployed by increasing the version number in blocks
> (as is done for soft forks), then there is no risk-- Full and SPV
> nodes should notice that they are seeing up-version blocks and warn
> the user that they are using obsolete software.
> 
> It doesn't matter if the software is obsolete because of hard or soft
> fork, the difference in risks between those two cases will not be
> understood by the typical full node or SPV node user.

Thanks for your comments.

In the case of a softfork, as long as an user waits for a few 
confirmations, the risk of money loss is very low. In the worst case 
they run a full node with SPV security. In the case of a hardfork, the 
consequence of failing to upgrade to the economic majority fork *is* 
fatal, even if an user waits for 1000 confirmations. Not to mention the 
risk of having 2 economically active forks. That's why wallets should 
STOP accepting and sending tx after a hardfork bit is detected and wait 
for users' instructions.

> " 3. In the case which the original consensus rules are also valid
> under the new consensus rules, users following the new chain may
> unexpectedly reorg back to the original chain if it grows faster than
> the new one. People may find their confirmed transactions becoming
> unconfirmed and lose money."
> 
> If a hard or soft fork uses a 'grace period' (as described in BIP 9 or
> BIP 101) then there is essentially no risk that a reorg will happen
> past the triggering block. A block-chain re-org of two thousand or
> more blocks on the main Bitcoin chain is unthinkable-- the economic
> chaos would be massive, and the reaction to such a drastic (and
> extremely unlikely) event would certainly be a hastily imposed
> checkpoint to get everybody back onto the chain that everybody was
> using for economic transactions.

No, the "triggering block" you mentioned is NOT where the hardfork 
starts. Using BIP101 as an example, the hardfork starts when the first 
 >1MB is mined. For people who failed to upgrade, the "grace period" is always zero, which is the moment they realize a hardfork.


> Since I don't agree with the motivations for this BIP, I don't think
> the proposed mechanism (a negative-version-number-block) is necessary.
> And since it would simply add more consensus-level code, I believe the
> keep-it-simple principle applies.
> 
> --
> 
> --
> Gavin Andresen