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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3DBB583D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:34:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BACA910D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:34:39 +0000 (UTC)
Received: from localhost ([::1]:54903 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZS0ha-000b9D-DM; Wed, 19 Aug 2015 06:34:38 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 19 Aug 2015 06:34:38 -0400
From: jl2012@xbt.hk
To: =?UTF-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
In-Reply-To: <CABm2gDrMome0xZGvPTYr9DaFJt=Si0Lmv=VTa4ydd4Bj6ARTcw@mail.gmail.com>
References: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
<CABm2gDrMome0xZGvPTYr9DaFJt=Si0Lmv=VTa4ydd4Bj6ARTcw@mail.gmail.com>
Message-ID: <4e57154a051f182bf9c4f939a61acad3@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
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]
=?utf-8?q?Bitcoin_is_an_experiment=2E_Why_don=27t_w?=
=?utf-8?q?e_have_an_experimental_hardfork=3F?=
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 10:34:40 -0000
Jorge Timón 於 2015-08-19 05:24 寫到:
> 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).
You misunderstand my intention. The experiment is not about a random
hardfork. It's about a block size increase hardfork. The data will help
us to design further hardfork on block size.
To make it less controversial, the size must not be too big.
To allow a meaningful experiment, the size must not be too small.
Technically we could make it 1.01MB but that defeats all objectives I
listed and there is no point to do it.
That's why I suggest 1.5MB.
>> 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.
I hope the fork could be done before the halving, which (hopefully) we
may have a new bitcoin rush
There was only 2 months for the BIP50 hardfork. You may argue that's a
"bug fix" but practically there is no difference: people not fixing the
bug in 2 months was forked off. Four months of grace period (Feb to June
2016) is already a double of that.
Also, if we could have zero grace period for softfork, why must we have
a ultra-long period for hardfork? (Unless you also agree to have an
1-year grace period for softfork. I don't buy the "softfork is safer
than hardfork" theory. The recent BIP66 fork has clearly shown why it is
wrong: non-upgrading full nodes are not full nodes)
The problem is many people won't update until they must do so. So 4
months or 1 year make little difference
|
