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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
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 DA4181BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 12:17:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com
[209.85.213.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8F5FA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 12:16:57 +0000 (UTC)
Received: by vkas68 with SMTP id s68so14764701vka.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Nov 2015 04:16:57 -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
:cc:content-type:content-transfer-encoding;
bh=w4m9x6utcJx5x1Gy4JjkA9lLlXjo9NQCYcvYgErNCcE=;
b=YDDfVXefJYYKVwMC90ZKLbAAwElCEj0hGrwkuGrRma1UNgGizmo+4SozyS9nUutBy2
hzyybbSge1zY+6Mck7pudWM8Mj48ARx2I3whfWhpr95Yq4v5uszb9nysFG+mblKuZfUi
trsw5ZUi7J/vGl11QtIBcWLVrxnv9HngR7P7yuGgxM7M43Ooj3mc5kxR+wCCGROj73QD
5yhA1hm0X9HGsRuP/KDS17rkLIyI3vdNBnZrijUUw6Ps/jSllpnHWgGOR+tO9e1qe92+
96jQRuDUkVqhIQc5c62WfQ0AINT3Bx2Lo9r76ltBNjMIx6nVt4ZfPfIpSE+N7ctQDLos
ll2Q==
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
:content-transfer-encoding;
bh=w4m9x6utcJx5x1Gy4JjkA9lLlXjo9NQCYcvYgErNCcE=;
b=aeXgwFQoCi3k96SfhU5SHuYSXx9o7T70xIrD/+EXl1xBojCqD8txviZE2kGucBIQU9
k3Er2r/Gt1Y+P0SbMJaeWF5VtLIksENwbaOPwNACbvsh9d+N60NgwRCm50JOqGR0L+sX
5YGA1/y/WPDnz473aAdluWoaL+6IL9PLxxlxdVNXdAu18Zp/Kpw8BS9I/+MPa48poas3
lh8yFHm06uVFHhWopWpnXjTUbWimVISWr+Kflm5rUbNO932/5NkgsYyF+OqGBxZQoJ69
qYumjw9Sw2KLp5BSBAo9C23tnoWLG7IpxhMgYWh+NhgOJbYrvYC40eQvSnJ/HIuOiNQC
874Q==
X-Gm-Message-State: ALoCoQkH7RZ34M7aTXRtVfAGZz5XtXyw/PZgV04mO3B+1Inqswp9cW1m0M/qg4C7+9mlmh4RyCBV
MIME-Version: 1.0
X-Received: by 10.31.151.9 with SMTP id z9mr7618156vkd.38.1447589817069; Sun,
15 Nov 2015 04:16:57 -0800 (PST)
Received: by 10.31.132.147 with HTTP; Sun, 15 Nov 2015 04:16:56 -0800 (PST)
In-Reply-To: <201511142127.53255.luke@dashjr.org>
References: <201511132228.47815.luke@dashjr.org>
<201511142111.24046.luke@dashjr.org>
<CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>
<201511142127.53255.luke@dashjr.org>
Date: Sun, 15 Nov 2015 13:16:56 +0100
Message-ID: <CABm2gDryvFsnnV=8Bwc8mQX4JtU9_PgJ0EBhcYjpcSdXjV2_WA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Dashjr <luke@dashjr.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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
John Sacco <johnsock@gmail.com>
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: Sun, 15 Nov 2015 12:17:01 -0000
On Sat, Nov 14, 2015 at 10:11 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Saturday, November 14, 2015 10:52:12 AM Jorge Tim=C3=B3n via bitcoin-d=
ev wrote:
>> Currently bip99 recommends 95% miner upgrade confirmation with version b=
its
>> (bip9) for uncontroversial hardforks just like it does for uncontroversi=
al
>> softforks. It is true that in the case of hardforks miners don't decide =
and
>> it's the whole economy who has to upgrade before activation, but "the wh=
ole
>> economy" and "all users" includes miners, so why not use the only upgrad=
e
>> confirmation mechanism that we have available?
>
> Actually, the economy does not necessarily include miners, and in fact th=
e
> present miner community for the most part does not overlap significantly =
with
> economic activity.
Maybe we should define "the bitcoin economy" is first. In my
definition, miners are definitely part of the economy (and also users
of the system).
On Sat, Nov 14, 2015 at 10:27 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote:
>> "the economy does not necessarily include miners"
>> so the money supply isn't part of the economy?
>
> Not in the context of economic majority deciding hardforks. After all, th=
e
> outcome of the hardfork *determines* the money supply. So the former mone=
y
> supply not supporting the change would just mean they cease to be involve=
d in
> that capacity. But even aside from that, the more relevant factor in term=
s of
> economic involvement is /acceptance/ of bitcoins as payment for real good=
s.
Miners accept bitcoins as payment for a real service (with real costs
like electricity) to the network: extending the longest valid chain
with their proof of work.
In the context of BIP99, there's no concept of "an economic majority"
deciding hardforks. Hardforks are either uncontroversial, in which
case BIP99 recommends 95% miner upgrade confirmation in addition to a
time threshold, or are schism hardforks (for example, an anti-miner
hardfork), in which case BIP99 recommends using a time threshold
alone. But no majority can force the dissenting users to use one
validation rule set or the other: users will always be free to run
whatever free software they like.
> And at the same time, miners also have a tendency to
> upgrade at a different rate than the economy.
That alone seems like a very good reason in favor to confirm that
miners have upgraded in addition to a minimal activation block median
time, not a reason against it
> It might make sense to
> incorporate a miner-trigger, but *only if* the flag is enabled in nodes b=
y an
> option disabled by default, and the BIP clearly specifies that miners mus=
t not
> enable it until they perceive complete economic adoption of the change.
I'm not sure I understand this. The trigger mechanism must be uniform
for each rule change, it cannot be optionally different or consensus
can fail.
How are miners supposed to "perceive" adoption?
The time threshold must be set enough in the future to give users time
to upgrade. But we can perceive miners' adoption, so if the system
knows they 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 unfortunately there's none).
Please, remember that this is in the context of uncontroversial
hardforks for which all users (including all miners) are expected to
upgrade to.
To reiterate, schism hardforks are treated differently and the miner
upgrade confirmation becomes completely irrelevant.
|
