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
|
Return-Path: <gacrux@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 87B018B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 13:51:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com
[209.85.217.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D4237149
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 13:51:03 +0000 (UTC)
Received: by lbbwc1 with SMTP id wc1so45945858lbb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 06:51:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:in-reply-to:references:mime-version
:content-transfer-encoding:content-type:subject:from:date:to:cc
:message-id; bh=53BPt1MlqGiAaCZGFESJYhCwD7aXIUMZP1hk0kNacuI=;
b=g68iJAmxir+ElKXwRCPMTwHDgCQEJVQDoSBC3MnvP7HXsnzmyurCaEJYb6YVyAqoFi
397ntoHGodsHIyp4NJtYZ7/WzXN3qcM8unuNrwLH6DcfSjBvZ2FLV/7MX8JywjpS+Qun
4Hi9KWdT5bikjstmwRYocNbkwCkEINInxb/Uc7UyLQtSEbtl9OLqEOUc2Bqw0eU2MZa0
XL+1Heo+gXBF+r5rOjOZ35QINh0T/FtG0vmixvVMYNKltvXL5lDU2/Sto5c8N4zFLBJC
YyLOHeVqQuUYpcIp1jYSOgGibaNBGlHzGoE9c9c2M0pZHKepnD3eLpiXQjxDlQRRRWBY
bxzQ==
X-Received: by 10.152.6.132 with SMTP id b4mr42181064laa.53.1435240262078;
Thu, 25 Jun 2015 06:51:02 -0700 (PDT)
Received: from [192.168.1.2] (2.tor.exit.babylon.network. [149.202.98.160])
by mx.google.com with ESMTPSA id rl1sm5796007lac.14.2015.06.25.06.50.55
(version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 25 Jun 2015 06:51:00 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@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>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
From: Gareth Williams <gacrux@gmail.com>
Date: Thu, 25 Jun 2015 23:50:41 +1000
To: Jeff Garzik <jgarzik@gmail.com>,William Madden <will.madden@novauri.com>
Message-ID: <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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@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: Thu, 25 Jun 2015 13:51:04 -0000
On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik@gmail.com> wrote:
>Miners can collude today to lower the block size limit.
Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?
You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway.
Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.
* but with a safer "supermajority" than 75% please :)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
