diff options
| author | jl2012 <jl2012@xbt.hk> | 2015-08-01 16:23:23 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-01 20:23:26 +0000 |
| commit | d6898efc80e9134a3737ec4b72ae4804ac1f5b4b (patch) | |
| tree | 66f9603f7c61475416b51508b7a03c3485a33ca3 | |
| parent | 35d919dac658af1537a725fdf3f6a063b504d27f (diff) | |
| download | pi-bitcoindev-d6898efc80e9134a3737ec4b72ae4804ac1f5b4b.tar.gz pi-bitcoindev-d6898efc80e9134a3737ec4b72ae4804ac1f5b4b.zip | |
Re: [bitcoin-dev] BIP draft: Hardfork bit
| -rw-r--r-- | 5d/af94b630dc157bb04c5936033bb1d66b467550 | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/5d/af94b630dc157bb04c5936033bb1d66b467550 b/5d/af94b630dc157bb04c5936033bb1d66b467550 new file mode 100644 index 000000000..7c0c8dafc --- /dev/null +++ b/5d/af94b630dc157bb04c5936033bb1d66b467550 @@ -0,0 +1,150 @@ +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 8970865 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Aug 2015 20:23:26 +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 679FED5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Aug 2015 20:23:25 +0000 (UTC) +Received: from localhost ([::1]:57507 helo=server47.web-hosting.com) + by server47.web-hosting.com with esmtpa (Exim 4.85) + (envelope-from <jl2012@xbt.hk>) + id 1ZLdJT-001oaA-NU; Sat, 01 Aug 2015 16:23:23 -0400 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8; + format=flowed +Content-Transfer-Encoding: 8bit +Date: Sat, 01 Aug 2015 16:23:23 -0400 +From: jl2012@xbt.hk +To: Michael Ruddy <mruddybtc@gmail.com> +In-Reply-To: <CABFP+yNgzNBtsfgHMNSJKpJmgD8jK13KRFP_P9+50ekiBoHfmQ@mail.gmail.com> +References: <20150723162321.Horde.bphh__8AhyXa_m-YAYpiyw1@server47.web-hosting.com> + <CAE-z3OWZGsSS2s1OZU5ScH7C4BcOtCb9mcz62TA7HZQe_=y0uA@mail.gmail.com> + <20150723192633.Horde.cGMZGo9Ji0-_9HZhcSUpww5@server47.web-hosting.com> + <CABFP+yNgzNBtsfgHMNSJKpJmgD8jK13KRFP_P9+50ekiBoHfmQ@mail.gmail.com> +Message-ID: <2c9dd1c02fc550438d4bbab29e052f34@xbt.hk> +X-Sender: jl2012@xbt.hk +User-Agent: Roundcube Webmail/1.0.5 +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-Source: +X-Source-Args: +X-Source-Dir: +X-From-Rewrite: unmodified, already matched +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW + 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@lists.linuxfoundation.org +Subject: Re: [bitcoin-dev] BIP draft: Hardfork bit +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: Sat, 01 Aug 2015 20:23:26 -0000 + +Although the chance is very slim, it is possible to have multiple +hardforks sharing the same flag block. For example, different proposals +may decide the flag time based on voting result and 2 proposals may have +the same flag time just by chance. The coinbase message is to preclude +any potential ambiguity. It also provides additional info to warning +system of non-upgrading nodes. + +If we are pretty sure that there won't be other hardfork proposal at the +same time, the coinbase message may not be necessary. With some prior +collaboration, this may also be avoided (e.g. no sharing flag block +allowed as consensus rules of the hardforks) + +The "version 0" idea is not compatible with the version bits voting +system, so I have this hardfork bit BIP after thinking more carefully. +Otherwise they are technically similar. + +Michael Ruddy 於 2015-08-01 09:05 寫到: +>>> Ok, so set the bit and then include BIP-GIT-HASH of the canonical BIP +>>> on +>>> github in the coinbase? +>> +>> +>> I guess the git hash is not known until the code is written? (correct +>> me if +>> I'm wrong) As the coinbase message is consensus-critical, it must be +>> part of +>> the source code and therefore you can't use any kind of hash of the +>> code +>> itself (a chicken-and-egg problem) +>> +> +> I took Tier's comment to mean that the commit hash (taken from git) of +> the BIP for the particular hard fork being rolled out via your hard +> fork bit mechanism could be used in the coinbase. +> The commit for the BIP is separate from the commit for the code +> changes implementing it. +> +> By using the commit hash of the BIP, it means that the BIP cannot +> specify itself what to put in the coinbase. +> I'd suggest that your hard fork bit proposal allows BIP authors to +> specify, within a 20 byte limit (to let them ripe160 a message or +> something), the unique value to use. +> This would be just as well and would allow the specific hard fork BIPs +> to be updated without having to make code changes (e.g.- for simple +> grammatical updates, post deployment clarification, etc...). +> +> Perhaps more preferable, in order to keep the coinbases small, or, if +> you're worried about BIP authors using duplicate values, then just +> specify in your proposal that the coinbase message include +> "BIP<NUMBER>" as BIP numbers are not going to be reused. All you are +> trying to achieve is something that can be uniquely pattern matched. +> +> Are the reasons for your use of the coinbase message 1) to guard +> against one or more hard forks piggy-backing on another's flag block, +> without prior collaboration, and 2) to have a nicer message in the +> alerting system? If so, you might want to spell that out in your +> proposal. At first, I was thinking that the coinbase thing was not +> entirely necessary since the possibility of multiple hard forks taking +> place concurrently is low. Multiple forking changes could be +> coordinated to all use the same possible voting mechanisms, median +> timestamp, and thus flag block. But if the concern is about competing +> hard forks where two or more forks abandon the original chain and +> attempt to use the same checkpoint block, then I can see why you'd +> need it. +> +> I was reading this proposal alongside another of your messages +> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009520.html) +> proposing a version 0 or even a >1MB block in the specific case of a +> block size limit hard fork. I can see the >1MB flag block creating DoS +> banning problems. That's more of a practical issue than a consensus +> issue due to the existing mono-culture of full nodes. So, currently a +>> 1MB flag block is not as appealing as a version 0 or this hard fork +> bit proposal. Besides the DoS ban, the >1MB proposal would mean that +> older nodes do not have the chance to notice a fork is happening (for +> alerting) as they would with a version 0 or hard fork bit. +> +> A version 0 flag block would not be able to contain any transactions +> unless the flag block version was assumed to be that of the most +> recent version at the time. This is because we'd want to enforce the +> rules of the previous soft forks that had been locked in. Other than +> that, the version 0 idea seems pretty similar to the hard fork bit +> proposal because you need more context than just the block itself to +> determine if it's a valid flag block (and this extra context is +> probably not great, but I don't have a better idea right now). +> +> Were those reasons part of why you progressed towards this hard fork +> bit proposal? + + |