diff options
author | jl2012 <jl2012@xbt.hk> | 2016-02-04 12:56:42 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-02-04 17:56:44 +0000 |
commit | 1e9eba3972feeb4a61e3c7f58eaa848319a726f9 (patch) | |
tree | 754a608bc80fd3cc4886e3c14a11d6cf3e8dd16f /f4 | |
parent | 588b04d2418577bfd1ae2ec8144ddc000bf7a95f (diff) | |
download | pi-bitcoindev-1e9eba3972feeb4a61e3c7f58eaa848319a726f9.tar.gz pi-bitcoindev-1e9eba3972feeb4a61e3c7f58eaa848319a726f9.zip |
Re: [bitcoin-dev] Hardfork bit BIP
Diffstat (limited to 'f4')
-rw-r--r-- | f4/edfca78d9b0add3857675c31f62580855c817a | 121 |
1 files changed, 121 insertions, 0 deletions
diff --git a/f4/edfca78d9b0add3857675c31f62580855c817a b/f4/edfca78d9b0add3857675c31f62580855c817a new file mode 100644 index 000000000..ae14bd693 --- /dev/null +++ b/f4/edfca78d9b0add3857675c31f62580855c817a @@ -0,0 +1,121 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id A57F0EFC + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Feb 2016 17:56:44 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42551144 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 4 Feb 2016 17:56:44 +0000 (UTC) +Received: from [::1] (port=47772 helo=server47.web-hosting.com) + by server47.web-hosting.com with esmtpa (Exim 4.86) + (envelope-from <jl2012@xbt.hk>) + id 1aRO95-004OOE-31; Thu, 04 Feb 2016 12:56:43 -0500 +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> +X-Sender: jl2012@xbt.hk +User-Agent: Roundcube Webmail/1.0.6 +X-AntiAbuse: This header was added to track abuse, + please include it with any abuse report +X-AntiAbuse: Primary Hostname - server47.web-hosting.com +X-AntiAbuse: Original Domain - lists.linuxfoundation.org +X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] +X-AntiAbuse: Sender Address Domain - xbt.hk +X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: + jl2012@xbt.hk +X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk +X-Source: +X-Source-Args: +X-Source-Dir: +X-From-Rewrite: unmodified, already matched +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Hardfork bit BIP +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 04 Feb 2016 17:56:44 -0000 + +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 + + |