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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E09D78FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 13:22:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com
[209.85.192.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7657989
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 13:22:27 +0000 (UTC)
Received: by qged69 with SMTP id d69so3561304qge.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 06:22:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=SG/buvI0Vz8hOIahqh7cECIJBQfEjn9dL8ul8dd0MvE=;
b=ZeeAvZf18RBhPYhKgNoRrBzm4p4YkDsW3Zq80Ye3PTc8Z1XbNljCmkbsUHmm9aMebB
SI89ZVwMrDB2ZAwZTfvT//tJn4UM11R+9dizB+KAUjQc5PRtUyvHxKRYHT7ml5mWBiVo
CMmTOlFRrbn73Bs9+fGAsHUkvQhpZagOjQMlLTKnRvxN9ErGlwiNNwPfB0j519dbDBr/
1n3ZSWA2yXoh8bnBrbN5uemIk5co0iqvOuSizVJ22DfpI9Ss8GVUw4D+SYvCCIClAadU
eZ5U6XMdRs5Jb997j4FIhGMVpSDI/KhFKUzxz+ouoKsKOAbG0UIpDb/lHcCMj65z5YmZ
nHQA==
MIME-Version: 1.0
X-Received: by 10.140.196.8 with SMTP id r8mr24437719qha.25.1439990546833;
Wed, 19 Aug 2015 06:22:26 -0700 (PDT)
Received: by 10.140.31.181 with HTTP; Wed, 19 Aug 2015 06:22:26 -0700 (PDT)
In-Reply-To: <CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
References: <20150819055036.GA19595@muck>
<CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
Date: Wed, 19 Aug 2015 14:22:26 +0100
Message-ID: <CAE-z3OWjvR73jHrGhozxgqr_QUDu_hvDmHJWdiEGOcAGMB9oqA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11431b180626a6051da9ed88
X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
MALFORMED_FREEMAIL,
MISSING_HEADERS,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
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: Wed, 19 Aug 2015 13:22:28 -0000
--001a11431b180626a6051da9ed88
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> We can use nVersion & 0x8 to signal support, while keeping the consensus
> rule as nVersion >= 4, right? That way we don't waste a bit after this all
> clears up.
>
What happens if XT gets 40% and this BIP gets 55%? That gives 95% that
accept the upgrade. Version 3 and lower blocks need to be rejected after
that.
By advertising 0x7 for the last 3 bits, XT is effectively claiming to
support the check locktime verify BIPs but they don't have the code.
This sequence could be used, without a specific version-bits proposal.
Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit
set, then reject blocks with version numbers less than 8.
At height N, if the above rule is active, then the BIP is permanent.
It applies to any block with bit 0x8 set, once the 75% threshold is met.
From height N + 5000 to N + 10000, reject blocks which have bit 0x8 set.
N could be set 1 year from now, or so.
This gives a period of time after lock that bit 8 is kept and then a period
where is is guaranteed to be zero.
This gives software that is only watching the bit time to be upgraded and
similarly time where the bit is set to zero before it can be reused.
--001a11431b180626a6051da9ed88
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <span dir=3D"=
ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><p dir=3D"ltr">We can use nVersion & 0x8 to=
signal support, while keeping the consensus rule as nVersion >=3D 4, ri=
ght? That way we don't waste a bit after this all clears up.</p></block=
quote><div></div>What happens if XT gets 40% and this BIP gets 55%?=C2=A0 T=
hat gives 95% that accept the upgrade.=C2=A0 Version 3 and lower blocks nee=
d to be rejected after that.<br><br>By advertising 0x7 for the last 3 bits,=
XT is effectively claiming to=20
support the check locktime verify BIPs but they don't have the code.<br=
><br></div><div class=3D"gmail_quote">This sequence could be used, without =
a specific version-bits proposal.<br></div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote"></div><div>Until height =3D N + 5000, if 95=
0 of the last 1000 blocks have the 0x8 bit set, then reject blocks with ver=
sion numbers less than 8.<br><br></div><div>At height N, if the above rule =
is active, then the BIP is permanent.=C2=A0 <br><br>It applies to any block=
with bit 0x8 set, once the 75% threshold is met.<br><br></div><div>From he=
ight N + 5000 to N + 10000, reject blocks which have bit 0x8 set.<br></div>=
<div><br></div><div>N could be set 1 year from now, or so.<br></div><br><di=
v><br></div><div>This gives a period of time after lock that bit 8 is kept =
and then a period where is is guaranteed to be zero.<br><br></div><div>This=
gives software that is only watching the bit time to be upgraded and simil=
arly time where the bit is set to zero before it can be reused.<br></div></=
div></div>
--001a11431b180626a6051da9ed88--
|
