summaryrefslogtreecommitdiff
path: root/10/c2185cabe58377d89d50cbd43fefc79a4bc345
blob: e0e6d71a344a709d0d6df670a70b4fe9f00fe106 (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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BBF3410A7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Jan 2016 18:50:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
	[209.85.213.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22864131
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Jan 2016 18:50:16 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id e185so46910600vkb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Jan 2016 10:50:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=VJTUwkGiXOjYbwK46A8SPu/1fr04IrO7ljnZNBkIJy4=;
	b=C7YhkOnxB1TeVwDGMtKjGaMkvl6YobaVWMgdpS/gbQpKbbEBWrh12Jn1iCDkbh3x1w
	Ix56TrAmAiHWHtYhsGxEGzLEDbNEho0liBuxqDafgbrq8yj3ia8ukaVefvH9HAt5Sii0
	q9qDH4SUCtMbYuKfeY6lY0OxI+E3BZN7/0hdXfhj4n+wo1tbRH0C52+9FLrF8wCiTabW
	DiaycgrpemTSr9fqOW4SL1GS77WHTe50U77XEIaAj7cxQgoHvlNa6rtHZYTkaV9X0c0X
	AcTAS/WlEcS6AawZzSPfG8qJYDlJveDs8KWVb0drpF7TPruDIQ7GxA8ICs0uMbhHoKip
	V5Xw==
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:to:cc:content-type;
	bh=VJTUwkGiXOjYbwK46A8SPu/1fr04IrO7ljnZNBkIJy4=;
	b=Up/6G9pCl2dVtXI9MkInQADk942tss3zQP65Az3ASrv7S4qc+FmqDqb19t3BkeljcS
	EXvBTUUnDoxwHU1tunPHvB3BAy+NGhUj3JHCTvfFNl4Ky39bkfmw1idWEw6g5GQ6aGfA
	i3GY+7xwgw834gHtIY+rgklThSJKQHpuvO1VHH0EDJjjsfCD8Rtv/zR554AxEVWjFhXY
	JmrpCZ2fGRjFL0CAs7hgyXi5VU0v/DHi/kaSityZ7VpqUs7oqrOA84ZNBxChUKgi90N9
	sGCpzTJx8bc9gR0NKt9Hu/TPEXA66n65RhVnNRSog35Y3wIIIXvUbUXWXcTPywQq7spP
	Y+Qg==
X-Gm-Message-State: AG10YORQiR2TAXnYodhO8yq6C4dna0hygo3NusHs9PYZjxEGGXWzQO7p9tkLKCE4eyDPm1u6Fmo5T9P+D9GMVA==
MIME-Version: 1.0
X-Received: by 10.31.149.3 with SMTP id x3mr6861481vkd.46.1454093415072; Fri,
	29 Jan 2016 10:50:15 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Fri, 29 Jan 2016 10:50:14 -0800 (PST)
In-Reply-To: <CABsx9T0oY2OuPCRgnQmqbLOBSQVd-yuQ8mMXjfzYpJTjXn8woQ@mail.gmail.com>
References: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
	<CABsx9T0oY2OuPCRgnQmqbLOBSQVd-yuQ8mMXjfzYpJTjXn8woQ@mail.gmail.com>
Date: Fri, 29 Jan 2016 19:50:14 +0100
Message-ID: <CABm2gDrQxUUfQA07309LSMZMb-j4Kxutc41F+fUK+E8yHNNj6Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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] Best (block nr % 2016) for hard fork activation?
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, 29 Jan 2016 18:50:16 -0000

On Fri, Jan 29, 2016 at 5:39 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> It doesn't matter much where in the difficulty period the fork happens; if
> it happens in the middle, the lower-power fork's difficulty will adjust a
> little quicker.

The reason why BIP9 (versionbits) only checks for new activations
during difficulty retargettings is a simple optimization to only check
1/2016 of the blocks.
I suspect the check itself is not that costly for Bitcoin Core, which
has all the block headers in memory anyway, but I don't think we
should assume that will be the case for all implementations.

<BIP99 aside comment>
As an aside, BIP99 never recommends a 75% mining signaling activation
threshold: it recommends 95% for uncontroversial rule changes and no
miner signaling at all for controversial hardforks.
I still have to update BIP99 with some later changes I commented at
Scaling Bitcoin HK like signaling hardfork activation with the
"negative int32_t bit" so that old clients are forced to
upgrade/decide. We could start deploying better ways to inform users
about a hardfork event, but of course those changes cannot be applied
to older software that is already deployed (but hopefully they will
still notice something is weird is happening if the longest chain that
keeps growing is invalid because it contained a block with a negative
version in it).
But I'm yet to see a single hardfork proposal that follows BIP99's
recommendations besides the hardfork proposed in BIP99 itself, which
should consist on a manageable list of very simple to deploy fixes
like the timewarp fix forward-ported from Freicoin 0.8 for the BIP. I
haven't seen much interest in growing that little list of "a few fixes
nobody disagrees are bugs or sub-optimal design decisions, plus the
changes are easy to implement both separately and as a whole" either.
I cannot say I have seen any opposition at all to BIP99 as a hardfork
either, but I naively expected people would ask me to implement more
things for BIP99 besides
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
or even contribute the patches themselves. For all that, I don't
consider BIP99 a priority to work on and I plan to complete it at some
point later, unless there's a time limit for a BIP to be in the
"draft" state or something.
If someone else considers completing BIP99 a priority, I'm happy to
review and integrate things, though. Thanks again to all the reviewers
and contributors to the BIP at this time and I'm sorry that it has
been stuck for some time. Maybe the classification/recommendations
should have been a BIP without code and the hardfork proposal itself
should have been another one and that would have been clearer. I just
wanted to have some code on my first BIP (and as said the plan is
still to put more code at some point).
</BIP99 aside comment>