summaryrefslogtreecommitdiff
path: root/f4
diff options
context:
space:
mode:
authorjl2012 <jl2012@xbt.hk>2016-02-04 12:56:42 -0500
committerbitcoindev <bitcoindev@gnusha.org>2016-02-04 17:56:44 +0000
commit1e9eba3972feeb4a61e3c7f58eaa848319a726f9 (patch)
tree754a608bc80fd3cc4886e3c14a11d6cf3e8dd16f /f4
parent588b04d2418577bfd1ae2ec8144ddc000bf7a95f (diff)
downloadpi-bitcoindev-1e9eba3972feeb4a61e3c7f58eaa848319a726f9.tar.gz
pi-bitcoindev-1e9eba3972feeb4a61e3c7f58eaa848319a726f9.zip
Re: [bitcoin-dev] Hardfork bit BIP
Diffstat (limited to 'f4')
-rw-r--r--f4/edfca78d9b0add3857675c31f62580855c817a121
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
+
+