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
|
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 27AC3117C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 18:24:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
[209.85.213.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9EDB01C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 18:24:32 +0000 (UTC)
Received: by mail-ig0-f176.google.com with SMTP id mw1so65328440igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 04 Feb 2016 10:24:32 -0800 (PST)
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=Vepgsfi0tv6/3rLi+YcZVQ65r9Jp8qdi8F6rVJWXNC0=;
b=vFsP+O1H7UO5FiXW3X+8k/CWlcpDppaUgQO2J3Fui1sjulSZOX3vz/weGvc9Xl1kZE
GxnHhA0oOunzvmCJwowoFxvkLs0/ic7NfP6lEiQKvjpdrzO7tI4t8fwgMZDmJQI06MxX
QRn8n7cvX7uUwyH8Eji95qeb2YTQvGbpkJNnWPvZ68eD1gtLn2zHOweC3ZhLjsFO6wem
wF50Dsw+DyGioNzP7yiwHh3saEdKr2dzEBB59/vs9J4nDhb/RrL1soSNDbgdnv43wDpM
j14TCWvSiwqK6L0P0BJkRy7EtTxy9RsHC1iKbWVqPrhWMe6ZhTe0X5QEOOmZCg43AOix
zl+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:cc:content-type;
bh=Vepgsfi0tv6/3rLi+YcZVQ65r9Jp8qdi8F6rVJWXNC0=;
b=MU4bkBnoX6D/cl9hUqFwM8gYPT9xHQ2dlBRUvx69DoV2ZBYAxSic5d3/KEyjzx8+Gu
4+DQszYQZrBqs8U24gULVVQCOZI2SpBdIJCgmH/Q5q1+L1HjKRkC45wXAQypvYpgSM5R
PiKs4VG6h+sO1XhkIIFB9PlN0BLAxCf6jKGDrxn1pURxeZnVOCvcvBo1hc6xE45f+J0F
4btimoojH31MkXwQTGQ307qrRs5U2FlnOmK6M3H0t5n+4EmQkaxIaY4ICgGOJMgWZds1
kXjbkDv5K9vbSmlZqXPWezvKvEf81zOvW2aOKL/8QIN3CmnL40ADEk6+ISZUiiNNLS6L
ZaKw==
X-Gm-Message-State: AG10YOT0U1DzIp+aIhHaYTs8dqBHCTGU0aa0hEHWiQXQ88S1c2b1zZ1Goou4DZ970/dU9aLYqhYZae+4qNVmxQ==
MIME-Version: 1.0
X-Received: by 10.50.79.230 with SMTP id m6mr5610520igx.95.1454610272041; Thu,
04 Feb 2016 10:24:32 -0800 (PST)
Received: by 10.79.77.65 with HTTP; Thu, 4 Feb 2016 10:24:31 -0800 (PST)
In-Reply-To: <a4a8c42d8e6528dd7c0ae100958dd988@xbt.hk>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
<CABsx9T2VoWm04i_vQv7u0vXM6hdMBM29bnMSuv8RmMFMGxOdpg@mail.gmail.com>
<a4a8c42d8e6528dd7c0ae100958dd988@xbt.hk>
Date: Thu, 4 Feb 2016 18:24:31 +0000
Message-ID: <CAE-z3OUdemyEg7bLAm6=Vp_4_WXrS_dsM52Yo24TAnqFxVR3wg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e01229aaa8d4408052af5d890
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_IMAGE_ONLY_24,
HTML_MESSAGE,
HTML_SHORT_LINK_IMG_3, MALFORMED_FREEMAIL, MISSING_HEADERS,
RCVD_IN_DNSWL_LOW, T_REMOTE_IMAGE autolearn=no version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Hardfork bit BIP
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, 04 Feb 2016 18:24:33 -0000
--089e01229aaa8d4408052af5d890
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 4, 2016 at 5:56 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> No, the "triggering block" you mentioned is NOT where the hardfork starts.
> Using BIP101 as an example, the hardfork starts when the first >1MB is
> mined. For people who failed to upgrade, the "grace period" is always zero,
> which is the moment they realize a hardfork.
Clients have to update in some way to get the benefit of this right?
An SPV client which fully validated the header chain would simply reject
the hard forking header. Last time I checked, the Bitcoinj SPV wallet
ignored the version bits, and just followed the longest chain. Is that
still the case?
In fact, does Core enforce the 95% rule for the soft-forks before checking
for long forks? I am assuming that it happens when checking headers rather
than when checking full blocks.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--089e01229aaa8d4408052af5d890
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 T=
hu, Feb 4, 2016 at 5:56 PM, jl2012 via bitcoin-dev <span dir=3D"ltr"><<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span class=3D""></span>
No, the "triggering block" you mentioned is NOT where the hardfor=
k starts. Using BIP101 as an example, the hardfork starts when the first &g=
t;1MB is mined. For people who failed to upgrade, the "grace period&qu=
ot; is always zero, which is the moment they realize a hardfork.</blockquot=
e><div><br></div><div>Clients have to update in some way to get the benefit=
of this right? <br></div><div><br></div>An SPV client which fully validate=
d the header chain would simply reject the hard forking header.=C2=A0 Last =
time I checked, the Bitcoinj SPV wallet ignored the version bits, and just =
followed the longest chain.=C2=A0 Is that still the case?<br><div><br></div=
><div>In fact, does Core enforce the 95% rule for the soft-forks before che=
cking for long forks?=C2=A0 I am assuming that it happens when checking hea=
ders rather than when checking full blocks.<br></div></div></div></div><div=
id=3D"DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><table style=3D"border-top:1px=
solid #aaabb6;margin-top:30px">
<tr>
<td style=3D"width:105px;padding-top:15px">
<a href=3D"https://www.avast.com/sig-email" target=3D"_blank"><img src=
=3D"https://ipmcdn.avast.com/images/logo-avast-v1.png" style=3D"width: 90px=
; height:33px;"></a>
</td>
<td style=3D"width:470px;padding-top:20px;color:#41424e;font-size:13px;fo=
nt-family:Arial,Helvetica,sans-serif;line-height:18px">This email has been =
sent from a virus-free computer protected by Avast. <br><a href=3D"https://=
www.avast.com/sig-email" target=3D"_blank" style=3D"color:#4453ea">www.avas=
t.com</a>
</td>
</tr>
</table><a href=3D"#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width=3D"1" heigh=
t=3D"1"></a></div>
--089e01229aaa8d4408052af5d890--
|
