summaryrefslogtreecommitdiff
path: root/49/03e01d608e1fbac1b417dddbd6b0048c784901
blob: d130fa9e19ebb49e688857b55fea03a58b3dcf64 (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
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 542BA68
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 09:24:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com
	[209.85.217.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3D2514E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 09:24:13 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so120546171lbb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 02:24:12 -0700 (PDT)
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=w9Mqg1I6uEhsp/LxfxGwRLpoBT+SFhq1lhHiQHI9xAE=;
	b=hwVNILsVgQ2QeTVt5SL+c4OoYJEkaO5HBPZod1Kurd2NNc1l5woZmrbi5eWqfuvsPW
	9q2+90FOImnwms5XAFwbIpmcDxYzDWrGyNqMspIaWm4TK6rAnTs+8mIN2OpS57o8YBAS
	aSCcPb/knMr8dXXPqEMSfz0Bq+oV0Jc2dYKJOc9bCQfR5t3fammiJdtArh98PHAmDDDh
	9NeHLqy1UxP8Y1FtL3xu73vZxMjsj0qvm3A5wkIoO06OKj20JmkfkgxetI4XKm6yzJTq
	y7zC2NjxlhDLy5PQtxLmq55wz2YqvfYkoUcTD0KLHCY7KwzkVuPbCnus6ps1Xx7Vxymy
	ignw==
X-Gm-Message-State: ALoCoQlU2Y+xXK1QIhrYWGEsJLG4bB4+p59yjMCL90E9rw6l38d5stxzUUqsDZoLauxa7GqUrejx
MIME-Version: 1.0
X-Received: by 10.152.37.196 with SMTP id a4mr10498105lak.59.1439976251936;
	Wed, 19 Aug 2015 02:24:11 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 02:24:11 -0700 (PDT)
In-Reply-To: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
References: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
Date: Wed, 19 Aug 2015 11:24:11 +0200
Message-ID: <CABm2gDrMome0xZGvPTYr9DaFJt=Si0Lmv=VTa4ydd4Bj6ARTcw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: jl2012@xbt.hk
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Bitcoin is an experiment. Why don't we have an
 experimental hardfork?
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 09:24:18 -0000

On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> As I understand, there is already a consensus among core dev that block size
> should/could be raised. The remaining questions are how, when, how much, and
> how fast. These are the questions for the coming Bitcoin Scalability
> Workshops but immediate consensus in these issues are not guaranteed.
>
> Could we just stop the debate for a moment, and agree to a scheduled
> experimental hardfork?
>
> Objectives (by order of importance):
>
> 1. The most important objective is to show the world that reaching consensus
> for a Bitcoin hardfork is possible. If we could have a successful one, we
> would have more in the future

Apart from classifying all potential consensus rule changes and
recommend a deployment path for each case, deploying an
uncontroversial hardfork is one of the main goals of bip99:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html

> 2. With a slight increase in block size, to collect data for future
> hardforks

The uncontroversial hardfork doesn't need to change the maximum block
size: there's plenty of hardfork proposals out there, some of them
very well tested (like the proposed hardfork in bip99).

> 1. Today, we all agree that some kind of block size hardfork will happen on
> t1=*1 June 2016*

I disagree with this. I think it should be schedule at least a year
after it is deployed in the newest versions.
Maybe there's something special about June 2016 that I'm missing.