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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A72E9B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 14:01:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com
[209.85.212.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A243E203
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 14:01:26 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so121083355wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 07:01:25 -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:to
:cc:content-type;
bh=X+7HThsa7itNiXXN4lMMq9b8G4sT8+k4JYBEEtEDAvo=;
b=VNar2jhvJRNTEzfz7t5UeQrM7dr+r3yVq/CN6flZT80rneZzVxOMD4yoUOuECqDLZK
Ew8EoLUr+kaTy9caJMIpenIVPT8D+q4iAu8omeIauBjpiGaEgy37P3Henjmd+tVOpAd+
wJzA7lh+HwklLmJDUPP9OOfgzetij3ApQ5GMvIZETkxuwRDtvLCEDGF8QsdePLvNRV+x
t6ZTdNv9z5f3MKzSRPuG9VL4EpuJ/GS6Bcg5tMLveuGN8/EdvjjSCMn11wRLrAtLZiBq
TgOp9thyfYqRQM/R0y/cyNYizIl4I3+HTvPF92Whx4F9AhOteat6jotVhdvRgPnJ+a2y
OnZw==
MIME-Version: 1.0
X-Received: by 10.195.18.5 with SMTP id gi5mr24955882wjd.0.1439992885510; Wed,
19 Aug 2015 07:01:25 -0700 (PDT)
Received: by 10.28.52.84 with HTTP; Wed, 19 Aug 2015 07:01:25 -0700 (PDT)
In-Reply-To: <CAE-z3OWjvR73jHrGhozxgqr_QUDu_hvDmHJWdiEGOcAGMB9oqA@mail.gmail.com>
References: <20150819055036.GA19595@muck>
<CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
<CAE-z3OWjvR73jHrGhozxgqr_QUDu_hvDmHJWdiEGOcAGMB9oqA@mail.gmail.com>
Date: Wed, 19 Aug 2015 10:01:25 -0400
Message-ID: <CADm_Wca+k3zd17jDLxkp4sbx1Mz8d4DmTG50jAzzAu4v7eU8hw@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c282146b8a08051daa787c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] 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 14:01:28 -0000
--001a11c282146b8a08051daa787c
Content-Type: text/plain; charset=UTF-8
A lot of this detail and worry is eliminated by simply asking BIP 102
maintainers to change to a different bit that works best for everyone.
Existing nVersion garbage will get buried in sufficient time window to
prevent anything from triggering.
Just settle on a specific standard, reserve bits for feature upgrade forks,
and move on. There is already a rough standard proposed in sipa's gist.
On Wed, Aug 19, 2015 at 9:22 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11c282146b8a08051daa787c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A lot of this detail and worry is eliminated by simply ask=
ing BIP 102 maintainers to change to a different bit that works best for ev=
eryone.=C2=A0 Existing nVersion garbage will get buried in sufficient time =
window to prevent anything from triggering.<div><br></div><div>Just settle =
on a specific standard, reserve bits for feature upgrade forks, and move on=
.=C2=A0 There is already a rough standard proposed in sipa's gist.</div=
><div><br><div><br></div><div><br></div><div><br></div></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 19, 2015 at 9=
:22 AM, Tier Nolan 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><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><sp=
an class=3D"">On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin=
-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></s=
pan> wrote:<br><blockquote 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 nVe=
rsion & 0x8 to signal support, while keeping the consensus rule as nVer=
sion >=3D 4, right? That way we don't waste a bit after this all cle=
ars up.</p></blockquote><div></div></span>What happens if XT gets 40% and t=
his BIP gets 55%?=C2=A0 That gives 95% that accept the upgrade.=C2=A0 Versi=
on 3 and lower blocks need 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>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a11c282146b8a08051daa787c--
|
