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
|
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 6CABC1CBB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 13:24:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE557299
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 13:24:55 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so114513291wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 06:24:54 -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=8r205dXrB4KFzGsIzG2ogngQeJhp3Z7eov3bkE+Kngk=;
b=Nb4UhLBwSjItNH+lHZ7ahiRuEyE6z/BrOaBYJU/vbuahTYAg3mmh6E7FN8GNpOD8s3
3jLjcmB5PGv9XcxvQSbgr74idDS6oF9fPERKOWbbrXJG+uUxuJ5GHAXnS/SEtRx+4FrZ
zcsSobHH2BpdG69PNjZILB3lIhNNhwpBg9rpoCHW6e9e9U7kx8zI786bm2kKjiojtN20
kzWLLoMc7pG7959NgHXwK3ELvdr1tJw8D0rIEeZCPGt4CaVpqAI0loTdmZECf9nadTQe
9Atqz98FSm6wTwHbcj3vyCK7FHQ9d/nPWHWzveA3v2ExKCjNv3fX50BKbKql3UC7FV4f
1xyg==
X-Gm-Message-State: ALoCoQkIkvBGibZmXx0OQrYVug7LUODvb6/QrwK3eGN5hRjVlTzXKAvE22BB7uemR0w6s5UbTUrt
MIME-Version: 1.0
X-Received: by 10.194.77.240 with SMTP id v16mr29192074wjw.109.1444051494308;
Mon, 05 Oct 2015 06:24:54 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Mon, 5 Oct 2015 06:24:54 -0700 (PDT)
In-Reply-To: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
Date: Mon, 5 Oct 2015 15:24:54 +0200
Message-ID: <CABm2gDoxzYWM2VSq1WLRSD61LaVNkQ2puwOEEuRP78s6+WRYCA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: NotMike Hearn <not.mike.hearn@gmail.com>
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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Mon, 05 Oct 2015 13:24:56 -0000
"Consensus" it's a term we use for consensus critical code and we
refer to different machines (potentially with different software)
validating in exactly the same way.
I think also using the term for people agreeing on what those
consensus rules is confusing, so in BIP99 I used the term
"uncontroversial" instead.
From BIP99 current's content (improvements welcomed):
"
Uncontroversial consensus upgrades
"Uncontroversial" is something though to define in this context. What
if a single user decides he won't upgrade no matter what and he
doesn't even attempt to explain his decision? Obviously, such a user
should be just ignored. But what if the circumstances are slightly
different? What if they're 2, 10 users? Where's the line? It is
possible that we can never have a better definition than "I know it
when I see it" [citation].
"
The fact that there's at least 3 different proposals for a blocksize
increase, that there's not a lot of data comparing different possible
block sizes and its potential effects on block propagation and that
the development progress has enormously slowed down during months of
discussion are, in my opinion, clear signs that none of the current
proposals are "uncontroversial", even by this vague definition.
I believe BIP65 is uncontroversial since no reasonable objections to
the feature itself have been raised, it has been widely reviewed and
tested. The only complain is about it is it's softfork deployment
mechanism.
Was deployment of bip16, bip30 or bip66 controversial (which were
deployed via softforks, some of them even with people [ie Mike Hearn]
preferring always hardforks over softforks) uncontroversial?
I believe they were all (maybe with the exception of bip16)
uncontroversial. That's the story bip99 is telling, but bip99 is not
finished so we can change that if it makes sense.
We could say that they have been "Unilateral softforks", but I don't
think that would be fair for the miners who helped deploy it. Or we
could always create a new category in bip99 (please, propose a new
category of softforks if you think there's some potential case that's
not covered).
This is not about Mike Hearn or you or any person in particular.
"Uncontroversial" is so far defined in a vague way, if you think you
can put a more formal definition forward, please do so (provided that
it's not an absurd definition which allows any individual to block
everything without reasonable arguments). I'm more than happy
improving bip99 before we move it from its current "draft" status.
If Mike Hearn (and you) are right, I should update bip99 to NEVER
recommend softforks for consensus rule changes.
But I still believe it is uncontroversial that softforks have great
advantages in many cases (even if not everybody understand this).
I want bip99 itself to be uncontroversial, so please nit/nack fast,
nit/nack often and please please please nit/nack on time (while bip99
is still a draft).
|