diff options
| author | jl2012 <jl2012@xbt.hk> | 2015-08-28 11:27:23 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-28 15:27:26 +0000 |
| commit | c198d8717fbf7ac9e4a360badc7e99fe014e5c13 (patch) | |
| tree | 84344c90f50e1a81d09e66bfcc9745274de30908 | |
| parent | f37b1893c5dfc7f07cd11365da38fec3db70fb17 (diff) | |
| download | pi-bitcoindev-c198d8717fbf7ac9e4a360badc7e99fe014e5c13.tar.gz pi-bitcoindev-c198d8717fbf7ac9e4a360badc7e99fe014e5c13.zip | |
Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations
| -rw-r--r-- | a4/662f00369dbdbf7d5133cc6ed0bae4f9ec71cb | 134 |
1 files changed, 134 insertions, 0 deletions
diff --git a/a4/662f00369dbdbf7d5133cc6ed0bae4f9ec71cb b/a4/662f00369dbdbf7d5133cc6ed0bae4f9ec71cb new file mode 100644 index 000000000..433fbdce2 --- /dev/null +++ b/a4/662f00369dbdbf7d5133cc6ed0bae4f9ec71cb @@ -0,0 +1,134 @@ +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 7B5F8F58 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Aug 2015 15:27: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 CBE52149 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Aug 2015 15:27:25 +0000 (UTC) +Received: from localhost ([::1]:56331 helo=server47.web-hosting.com) + by server47.web-hosting.com with esmtpa (Exim 4.85) + (envelope-from <jl2012@xbt.hk>) + id 1ZVLYp-001skK-KY; Fri, 28 Aug 2015 11:27:23 -0400 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8; + format=flowed +Content-Transfer-Encoding: 8bit +Date: Fri, 28 Aug 2015 11:27:23 -0400 +From: jl2012@xbt.hk +To: Peter Todd <pete@petertodd.org> +In-Reply-To: <20150827231913.GC4125@muck> +References: <20150827231913.GC4125@muck> +Message-ID: <c3aa6fd8d7f41a902ac1981921c37214@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 <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for + locktime calculations +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: Fri, 28 Aug 2015 15:27:26 -0000 + +I have an ugly solution to this problem, with minimal change to the +current softfork logic, and still allows all features described in +sipa's Version bits BIP + +1. xVersion = nVersion AND 0b10000000000000000000000000011000 +2. miners supporting BIP65 will set xVersion = 8 or greater +3. If 750 of the last 1000 blocks are xVersion >= 8, reject invalid +xVersion 8 (or greater) blocks +4. If 950 of the last 1000 blocks are xVersion >= 8, reject all blocks +with xVersion < 8 + +So the logic is exactly the same as BIP66, with the AND masking in step +1. After the BIP65 softfork is implied, xVersion may take only one of +the following values: 8, 16, 24 + +This is basically moving the "high bits" in sipa's proposal to the +middle of the nVersion field. After the BIP65 softfork, this will still +leave 29 available bits for parallel soft forks, just in different +position. + +This is ugly, but I believe this is the easiest solution + +Ref: https://gist.github.com/sipa/bf69659f43e763540550 + +Peter Todd via bitcoin-dev 於 2015-08-27 19:19 寫到: +> On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote: +>> This BIP was assigned number 113. +>> +>> I have updated the text accordingly and added credits to Gregory +>> Maxwell. +>> +>> Please see the changes in the pull request: +>> https://github.com/bitcoin/bips/pull/182 +> +> On Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev +> wrote: +>> I have changed BIPS 112 and 113 to reflect this amended deployment +>> strategy. I'm beginning to think the issues created by Bitcoin XT are +>> so serious it probably deserves converting OPs text into an +>> informational BIP. +> +> I thought we had decided that the masking thing doesn't work as +> intended? +> +> To recap, XT nodes are producing blocks with nVersion=0b001...111 +> +> You're suggesting that we apply a mask of ~0b001...111 then trigger the +> soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks +> with +> nVersion=0b0...1000 +> +> That will work, but it still uses up a version bit. The reason why is +> blocks with nVersion=0b001...000 - the intended deployment of the +> nVersion bits proposal - will be rejected by the nVersion >= 4 rule, +> hard-forking them off the network. In short, we have in fact "burnt" a +> version bit unnecessarily. +> +> If you're going to accept hard-forking some people off the network, why +> not just go with my stateless nVersion bits w/ time-expiration proposal +> instead? The only case where it leads to a hard-fork is if a soft-fork +> has been rejected by the time the upgrade deadline is reached. It's +> easy +> to set this multiple years into the future, so I think in practice it +> won't be a major issue for non-controversial soft-forks. +> +> Equally, spending the time to implement the original stateful nVersion +> bits proposal is possible as well, though higher risk due to the extra +> complexity of tracking soft-fork state. +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |