summaryrefslogtreecommitdiff
path: root/fd/3428bb315bab856baf5f3acedb7aeec7ddbcd9
blob: 6ba281b16ce822289af2246379c4629783cea97a (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
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 5243D71
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 Nov 2015 10:15:55 +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 E3EFD13D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 Nov 2015 10:15:54 +0000 (UTC)
Received: by ykdv3 with SMTP id v3so54981837ykd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 Nov 2015 02:15:54 -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
	:content-type:content-transfer-encoding;
	bh=tAY88sxyOOyCs2/P6U3NjK0modzvIWxLvB8hm2mo5kQ=;
	b=P4of7UDHWfA8KFW4/R0pz8AdyIe4mJgkKgYkjAEkubAEQbSGAlwu6wgKd9/Gs14iQn
	pnlTRuAxCF1w+egxzeTbm8k48sJtPGOzr/Pg/jukzY8GfBPgEwwFiRtdc6TCBaiXYxU4
	pHCK8fBvKZeFpzvRMcXpV6C/obQw4U6pspTk7bXne4SBUF4U/5Zya1qDi1nbJj6yuHcd
	nICK2lc8esWeUsOIp0vXl6QXIu4W8xA4IlsBI0akU/i8NQ9K9fZc32kq/bYkJv1uBOpp
	XSC/tGOumHptX3wGAzWRMupHisTwlllHo0TPT4Kw92vRrCJESzbRDvErlLke4Zdat/d5
	lv/g==
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:content-type:content-transfer-encoding;
	bh=tAY88sxyOOyCs2/P6U3NjK0modzvIWxLvB8hm2mo5kQ=;
	b=NaIztvtCp/n4Dt+1SOSTqeu8sXNkRLBYAl0QPTWmfh4kff2VKIsgMAxtDsb4b7Sbr5
	M3ep36fyh+RojI0KdDFCjpe2m9/1ua5I7cDrojPWoTIWt51etsZTbMLvqI5dY7LJivi5
	TqfupunC11X3jTjN7jfp1TK1Gn/NdqUod8K/nwI6NyoKDrp1SrA9x/CsBaEPsfnuSI3g
	jdXuyZR4qrAYNpWhfKs1JDxRl7iCbSj1ab4Y4dBMAtccYwHobRDJtexWW0PLlHCb6kSd
	VcyP5wXJdb6BWqEh9Hlg0/NUxNSLnNaKICj8sIOxzz1Ip5FLlG5qcfHW9g5u87Kw/kXG
	tKoQ==
X-Gm-Message-State: ALoCoQmXyBZtCNO8D5AtxZn0LgL+ng0bZwgpL6FuM2H+VTSOeXZI8R7q8AWPJKMDunBuF8gtHMPN
MIME-Version: 1.0
X-Received: by 10.13.250.69 with SMTP id k66mr653060ywf.107.1447841754211;
	Wed, 18 Nov 2015 02:15:54 -0800 (PST)
Received: by 10.31.132.147 with HTTP; Wed, 18 Nov 2015 02:15:54 -0800 (PST)
In-Reply-To: <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>
References: <201511132228.47815.luke@dashjr.org>
	<201511142111.24046.luke@dashjr.org>
	<CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>
	<201511142127.53255.luke@dashjr.org>
	<CABm2gDryvFsnnV=8Bwc8mQX4JtU9_PgJ0EBhcYjpcSdXjV2_WA@mail.gmail.com>
	<CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>
Date: Wed, 18 Nov 2015 11:15:54 +0100
Message-ID: <CABm2gDo30EhWmreaFBB81H6mvUwO=KpWz_c+uavsG1KBYGLgaw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Shuning Hong <hongshuning@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
X-Mailman-Approved-At: Wed, 18 Nov 2015 12:00:23 +0000
Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving
 with max block size of 32M
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, 18 Nov 2015 10:15:55 -0000

On Wed, Nov 18, 2015 at 10:13 AM, Shuning Hong <hongshuning@gmail.com> wrot=
e:
> 2015-11-15 20:16 GMT+08:00 Jorge Tim=C3=B3n <bitcoin-dev@lists.linuxfound=
ation.org>:
>> The time threshold must be set enough in the future to give users time t=
o upgrade. But we can perceive miners' adoption, so if the system knows the=
y haven't upgraded, it should wait for them to upgrade (it would be nice to=
 have an equivalent mechanism to wait for the rest of the users, but unfort=
unately there's none).
>
> If the majority of the miners never upgrade, how could we treat that
> BIP? Wait forever?

Assuming it was deployed as an uncontroversial hardfork as recommended
in BIP99, the deployment would use versionbits (BIP9) and the hardfork
would timeout.
But this timeout would clearly signal that either the minimum
activation threshold wasn't giving enough time for all users to
upgrade (apparently miners didn't had time) or the hardfork is not
really an uncontroversial hardfork but rather a schism one. Then,
assuming some people still want to deploy it as a schism hardfork,
bip99 recommends using only a mediantime threshold without versionbits
nor miner upgrade confirmation.