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
|
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 1C19C7AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:53:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com
[209.85.218.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8585C10D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:53:31 +0000 (UTC)
Received: by oiew67 with SMTP id w67so537761oie.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 03:53:31 -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=nPn+qjeIDKasgBDr5HaWP2bl6NMa4j4UsK18FDgNzo4=;
b=V7F6suFwebg7PcyI/GIIXImkHTiWgScYIzPVEjy4rGc5OGv4lKsVJf0uGcjZxMPLm6
/DMXnBdNt0yOxx745IgUqBHya2L+gNnzrMdVUbOYguA33mc32ZVwedRlehPkwqjeVda7
Ok2aMv3whbvdjLVtpGQCKVsdgF+i+3OPUyYuxyCPQohEdDziBRfeqw7TnftUX9DcTXN/
BwvXdoSwp8geqouN20/+NzeCzO/her6M5Go71BlOmwfmUZxysg1+dElQn9O/dQ26z7nb
UBqGoBAZDyaMdrIIoY0FTjYDZwHNgnIxGCZ818/hYRO013T0seD6yyFS9jh9ojAYq1Z2
mfBQ==
X-Gm-Message-State: ALoCoQk3OfDTjFGTZVD/s+sg5pyHdnhimzs1sht78eB/fgQItKEh/J5uFROEeaeSNf6UuzNkACu+
MIME-Version: 1.0
X-Received: by 10.202.58.133 with SMTP id h127mr9669682oia.35.1439981610860;
Wed, 19 Aug 2015 03:53:30 -0700 (PDT)
Received: by 10.202.71.85 with HTTP; Wed, 19 Aug 2015 03:53:30 -0700 (PDT)
In-Reply-To: <4e57154a051f182bf9c4f939a61acad3@xbt.hk>
References: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
<CABm2gDrMome0xZGvPTYr9DaFJt=Si0Lmv=VTa4ydd4Bj6ARTcw@mail.gmail.com>
<4e57154a051f182bf9c4f939a61acad3@xbt.hk>
Date: Wed, 19 Aug 2015 12:53:30 +0200
Message-ID: <CABm2gDpce_5CCeAGFqqDZvkC6aV9p-cU15OrG4PjMODFBKY45Q@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 10:53:32 -0000
On Wed, Aug 19, 2015 at 12:34 PM, <jl2012@xbt.hk> wrote:
> You misunderstand my intention. The experiment is not about a random
> hardfork. It's about a block size increase hardfork.
One of your goals is "show the world that reaching consensus for a
Bitcoin hardfork is possible", right?
BIP99 can achieve that goal without touching the block size (thus
probably less controversial).
> The data will help us
> to design further hardfork on block size.
The data can be collected using testchains. See #6382
> To make it less controversial, the size must not be too big.
That makes the data less interesting, doesn't it?
> 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.
It wouldn't defeat the "show the world that reaching consensus for a
Bitcoin hardfork is possible" objective though. But again, we don't
need to touch the block size to achieve that goal.
> That's why I suggest 1.5MB.
But that wouldn't be uncontroversial (unless it was accompanied with
data that somehow quantifies the risks, in which case maybe another
bigger size is acceptable).
>>> 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.
Yes, emergency hardforks are a different case as explained in BIP99's draft.
In any case, " we all agree that some kind of block size hardfork will
happen on June 2016" it's clearly false since I can find many
counter-examples besides myself.
> 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)
I don't think giving 1 year for "everybody in the world" to upgrade is
an "ultra-long" period.
I'm proposing 5 years for the hardfork proposed in bip99.
I do think softforks are safer than hardforks, that doesn't mean
softforks don't have serious risks as well.
> The problem is many people won't update until they must do so. So 4 months
> or 1 year make little difference
I disagree with this conclusion as well (it doesn't follow from the
first sentence, non sequitur).
|
