summaryrefslogtreecommitdiff
path: root/fd/1b1c2e9371fae9d9c1dfb4704d3430c835c3e1
blob: d6677c72edc11f81a80cf46d73e1ff94214f7473 (plain)
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
135
136
137
138
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5352CEC6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Aug 2015 22:11:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com
	[209.85.160.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7819E16C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Aug 2015 22:11:30 +0000 (UTC)
Received: by ykdt205 with SMTP id t205so35985216ykd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Aug 2015 15:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=w+FevihYfncYBt/H94mV+sGoyUOUsABe2eOLAcowdsM=;
	b=eofEG/Z3M23Y4UXj+yl71QegIjNlU12pNP1m5dJi2exUHoAkJa5Bbm7fyZzwXlyFr8
	tTnkCgkkCcarCPq5xyYYU8lY5XPWlmVhq4jTdNfg2I959XVsIiUifyu0PtoSi2fBrJjj
	0aimBkC3+moisVtK8Y7eY44kR5XNxc1/CoiARxFeyUgCc8TDrNau6BLt55nfshkk1zFo
	mIAkC3mhCdJfvQJ1kxEQIdc6/ScJpHjxw9uqVTw8btzKuV5tcdEmBXr6S8tDUprsZXku
	02lHNQjrlfmQg9Hq437Ty4GfC0O0Ml7b2c5/Fn2E5xK+vlaEWQBpwOG3wz9MN8v5XOFm
	ajHg==
X-Received: by 10.13.218.131 with SMTP id c125mr5107429ywe.129.1440713489816; 
	Thu, 27 Aug 2015 15:11:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.94.132 with HTTP; Thu, 27 Aug 2015 15:11:10 -0700 (PDT)
In-Reply-To: <CAOG=w-tA0Rme_geadjaZCP4QRYb2T0y7PGCZ-QbjGVt2H+=z=w@mail.gmail.com>
References: <20150819055036.GA19595@muck>
	<c20a83f511d7023f9cdd2df4713cddf9@xbt.hk>
	<CAOG=w-tA0Rme_geadjaZCP4QRYb2T0y7PGCZ-QbjGVt2H+=z=w@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 27 Aug 2015 23:11:10 +0100
Message-ID: <CADJgMztcy33cW4=SOfsmANMFCU3Q7pcLqatG9JeJCgEXnpkD+g@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
	HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no 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] CLTV/CSV/etc. deployment considerations due to
 XT/Not-BitcoinXT miners
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, 27 Aug 2015 22:11:31 -0000

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.

On Thu, Aug 20, 2015 at 6:42 PM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> No, the nVersion would be >=3D 4, so that we don't waste any version valu=
es.
>
> On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Peter Todd via bitcoin-dev =E6=96=BC 2015-08-19 01:50 =E5=AF=AB=E5=88=B0=
:
>>
>>>
>>>
>>> 2) nVersion mask, with IsSuperMajority()
>>>
>>> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
>>> be masked away, prior to applying standard IsSuperMajority() logic:
>>>
>>>     block.nVersion & ~0x20000007
>>>
>>> This means that CLTV/CSV/etc. miners running Bitcoin Core would create
>>> blocks with nVersion=3D8, 0b1000. From the perspective of the
>>> CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners would b=
e
>>> advertising blocks that do not trigger the soft-fork.
>>>
>>> For the perpose of soft-fork warnings, the highest known version can
>>> remain nVersion=3D8, which is triggered by both XT/Not-Bitcoin-XT block=
s
>>> as well as a future nVersion bits implementation. Equally,
>>> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
>>> unknown bit set.
>>>
>>> When nVersion bits is implemented by the Bitcoin protocol, the plan of
>>> setting the high bits to 0b001 still works. The three lowest bits will
>>> be unusable for some time, but will be eventually recoverable as
>>> XT/Not-Bitcoin-XT mining ceases.
>>>
>>> Equally, further IsSuperMajority() softforks can be accomplished with
>>> the same masking technique.
>>>
>>> This option does complicate the XT-coin protocol implementation in the
>>> future. But that's their problem, and anyway, the maintainers
>>> (Hearn/Andresen) has strenuously argued(5) against the use of soft-fork=
s
>>> and/or appear to be in favor of a more centralized mandatory update
>>> schedule.(6)
>>>
>>
>> If you are going to mask bits, would you consider to mask all bits excep=
t
>> the 4th bit? So other fork proposals may use other bits for voting
>> concurrently.
>>
>> And as I understand, the masking is applied only during the voting stage=
?
>> After the softfork is fully enforced with 95% support, the nVersion will=
 be
>> simply >=3D8, without any masking?
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>