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
|
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 B4D7B895
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 16:11:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f49.google.com (mail-la0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E0C4EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 16:11:18 +0000 (UTC)
Received: by labd1 with SMTP id d1so82702852lab.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 09:11:16 -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=NcecRELCyrKNfvK+1poRWGajPfxFG364l1nM5yNfKsk=;
b=GCREyy86b5ctR1K3p65G5t5Ybl3xYSljLmJB48DC5H67nQU2pHQMecZWpsFmnWafRI
gW4q6sV3WG+dqZQSKnrENfYKzBp8h/KP45SkGlw1M1iShKkIoFdr5bXU8nwTR8cAByBt
mQAkHk8r4Ea8mnPw1+VAeChUGV9QFRoLo256Z0/1504aW5zJUtBJSyfT7AhiGYmM/uUG
arfDGZEZ35ll2d+BEcPLJV6PAAFVBOFErUzzYiRaL+PvOrGvMfKqBQgUN0fGsyGdghS6
J52fFgmItzLduqtOM245Lwh6yZYm40fkYUOyUgM2y4j8Jo6jZ3JdzSsGUN/ybX+BFxOQ
VsCQ==
X-Gm-Message-State: ALoCoQlH7PmJ2VPlx3eTPt32k/yuV8GDpeYM3ztLS5Zy7Aiezhl8v5GA1FLWabSidAaFMq8U4IAa
MIME-Version: 1.0
X-Received: by 10.112.89.201 with SMTP id bq9mr1712822lbb.39.1439827876581;
Mon, 17 Aug 2015 09:11:16 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Mon, 17 Aug 2015 09:11:16 -0700 (PDT)
In-Reply-To: <CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com>
<CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
<0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com>
<CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com>
<CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
Date: Mon, 17 Aug 2015 18:11:16 +0200
Message-ID: <CABm2gDrF_dGM9KrThSoAr4FP1KtbYTnKx433X1PmKRUXfXRiTQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tier Nolan <tier.nolan@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] Draft BIP : fixed-schedule block size increase
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, 17 Aug 2015 16:11:18 -0000
On Fri, Jun 26, 2015 at 3:47 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB
> minimum)
I don't think is all that interesting to make miners vote on lower
limit. Say the community wants to reduce the size to limit mining
centralization, it's not unthinkable that the hashrate majority (which
may have to face more competition or harvest less transactions after
the change) may oppose to that and then the community is forced to
deploy an anti-miner's hardfork (maybe even asic-reset hardfork?)
instead of a softfork.
Yes, uncontroversial sofforks are easier and less risky to deploy than
uncontroversial hardforks, but anti-miner hardforks are not.
Not only I don't think it's a good idea for miners to vote on the
block size (which is there to control them), I don't even buy the
assumption that "we can always just softfork a smallwer size later".
If you give something to miners they may not want to give it back later.
We could hardfork to 42 M supply and then "just softfork back to 21 M", right?
Or what's the same, we could "just softfork supply to 15 M". Such a
change would be clearly controversial among miners, so it wouldn't be
an uncontroversial softfork anymore. Some of these cases are discussed
in BIP99.
|
