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
|
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 067418D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 17:28:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com
[209.85.215.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69459106
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 17:28:40 +0000 (UTC)
Received: by lalv9 with SMTP id v9so7486283lal.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 10:28:39 -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=/5WbKPs8E8bv/p+0q04VKx8YN8jHklC5nL20s+G8hyY=;
b=Z+0NibS6ptcrzeDGbdDjwNjKTNg+4Ad5HP6tl8vUd53bbeyZBfLhDiLJ/zdilriNT3
QoMh+ZoOSydL182et62pnTLW/I88Gdmgx2aiCX6unGV4VkOZEhTPSgYTaCjlj9CnFVP9
aoWrrU0ekeyIFQ8e98BYSMC2wsMWirMFHlVXB9TWHOcFmunuTU1mSqF3N0hWJfO3/WeT
YdoTj4Q8EjrWTU4efIo1yfgq7b5XE8efKf4om8JxM2nRu196tg/IpEQWoWFWIt1vJoYq
TUxl7pB1blaSWUdsz8OauBBUHPsDnhRYwriFaDY03HEDszV8B6cGDJ3hWiDp/y6LrmFx
Jw3g==
X-Gm-Message-State: ALoCoQkWj9P8MsuKMNtYGmRs2/yHBbFyw1CKy7J0VxDx+aBLbOWJZ2DAfPGxOK1bbhdKdmEJK/Yv
MIME-Version: 1.0
X-Received: by 10.112.151.178 with SMTP id ur18mr12565140lbb.59.1440005318847;
Wed, 19 Aug 2015 10:28:38 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 10:28:38 -0700 (PDT)
In-Reply-To: <CALqxMTFkgGx0FxMiZ77inOZSs_+TQ88Wpj-q-c12COkO9tP4gQ@mail.gmail.com>
References: <CALqxMTFkgGx0FxMiZ77inOZSs_+TQ88Wpj-q-c12COkO9tP4gQ@mail.gmail.com>
Date: Wed, 19 Aug 2015 19:28:38 +0200
Message-ID: <CABm2gDrx3XEJX1WSAeyEpZ=cKb4-UB8tcFTKu8DMccZzfBsqYQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Adam Back <adam@cypherspace.org>
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 XT Fork
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 17:28:41 -0000
On Wed, Aug 19, 2015 at 6:53 PM, Adam Back via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> (and that in a hard fork it is not a miner vote really
> as in soft-forks).
I think calling it "miner vote" was the first mistake: miner's
shouldn't have a "voting power" the rest of the users lack.
I prefer to call it "miner upgrade confirmation" and in BIP99 the
recommendation is to use 95% for both uncontroversial softforks and
uncontroversial hardforks (the uncontroversial harforks also have a
minimum height before starting the miner confirmation/voting to give
users additional time to upgrade).
To me it's no different that the mechanism is used for uncontroversial
softforks or hardforks, the main question is that it is NOT a "miners'
democracy/oligopoly".
If you expect everyone (including all miners) to upgrade, I don't
think any less than 95% makes sense. On the other hand, 100% makes it
relatively cheap for an attacker to block uncontroversial consensus
changes.
For a Schism hardfork, bip99 doesn't recommend to use miner's
confirmation/vote at all. Miners could be against the change, for
example in an ASIC-reset Schism hardfork or in a "hardfork" (it cannot
be a softfork if miners oppose to it) to reduce the block size), but
that shouldn't stop the hardforkers if they think dividing the
currency in 2 is the best solution to whatever is the problem at hand
(which I don't think it's the case now).
Of course, BIP99 is still a draft and can still be changed. But I
would really like that we focused on "how to do hardforks in general"
first and only then focus on how to make a blocksize hardfork
concretely.
|
