From: Gavin Andresen <gavinandresen@gmail•com>
To: jl2012 <jl2012@xbt•hk>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
Date: Thu, 4 Feb 2016 12:36:06 -0500 [thread overview]
Message-ID: <CABsx9T2VoWm04i_vQv7u0vXM6hdMBM29bnMSuv8RmMFMGxOdpg@mail.gmail.com> (raw)
In-Reply-To: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]
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.
" 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.
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
[-- Attachment #2: Type: text/html, Size: 2941 bytes --]
next prev parent reply other threads:[~2016-02-04 17:36 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 [this message]
2016-02-04 17:56 ` jl2012
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=CABsx9T2VoWm04i_vQv7u0vXM6hdMBM29bnMSuv8RmMFMGxOdpg@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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