From: jl2012 <jl2012@xbt•hk>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
Date: Thu, 04 Feb 2016 12:56:42 -0500 [thread overview]
Message-ID: <a4a8c42d8e6528dd7c0ae100958dd988@xbt.hk> (raw)
In-Reply-To: <CABsx9T2VoWm04i_vQv7u0vXM6hdMBM29bnMSuv8RmMFMGxOdpg@mail.gmail.com>
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
next prev parent reply other threads:[~2016-02-04 17:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 17:14 jl2012
2016-02-04 17:36 ` Gavin Andresen
2016-02-04 17:56 ` jl2012 [this message]
2016-02-04 18:00 ` Bryan Bishop
2016-02-04 18:24 ` Tier Nolan
2016-02-04 18:19 ` Peter Todd
2016-02-04 18:29 ` Luke Dashjr
2016-02-05 10:20 ` Jorge Timón
2016-02-04 19:36 ` Gregory Maxwell
2016-02-04 22:15 ` Gavin Andresen
2016-02-05 9:58 ` Jorge Timón
2016-02-07 19:27 ` jl2012
2016-02-07 20:20 ` Gavin
2016-02-08 2:44 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a4a8c42d8e6528dd7c0ae100958dd988@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox