1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
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
|
