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
|
Return-Path: <roy@gnomon.org.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 54CBA93E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 21:00:59 +0000 (UTC)
X-Greylist: delayed 00:05:08 by SQLgrey-1.7.6
Received: from darla.gnomon.org.uk (darla.gnomon.org.uk [93.93.131.22])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 518C3121
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 21:00:58 +0000 (UTC)
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t5NKtfwJ017149
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Tue, 23 Jun 2015 21:55:46 +0100 (BST)
(envelope-from roy@darla.gnomon.org.uk)
Received: (from roy@localhost)
by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id t5NKteA6017148;
Tue, 23 Jun 2015 21:55:40 +0100 (BST) (envelope-from roy)
Date: Tue, 23 Jun 2015 21:55:40 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20150623205539.GB3192@giles.gnomon.org.uk>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<20150623192838.GG30235@muck>
<CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
RP_MATCHES_RCVD 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: Tue, 23 Jun 2015 21:00:59 -0000
> Consensus is that this process is too painful to go through once a year. I
> agree.
>
> If you disagree and would like to see a Blocksize Council meet once a year
> to issue a decree on what the maximum block size shall be for the next
> year, then propose a process for who gets to sit on the Council and how
> their decrees are enforced.....
We could just as well say that the increases continue for 20 years, or
until there is concensus to schedule a soft-fork to prevent further
increase - whichever comes first. That is the case already, of
course, since there is no way to prevent a modest supermajority of
miners from pushing through a soft-fork. But explicitly accepting the
possibility that the community might choose to cut the process short
might make the BIP more palatable to some.
It is also the reality: halting the blocksize increase before it hits
the final 8GB limit is relatively easy, compared to the task of
setting it in motion, so it does no real harm to set the "20 years"
figure at the upper range of what we think is reasonable - even though
under other circumstances one would probably say that extrapolating
exponentials that far out would be foolhardy...
roy
|
