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
|
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 9121747F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 17:46:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
[209.85.212.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D059F262
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 17:46:31 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so1869276wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 10:46:30 -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=U/2xZnOY0lzyPGaJqMDNWhSyVNEE/DLBcjZ1ueVGVwA=;
b=dqsSiXmnosy78IJwg/ezRQhVsrIydO6G/o9uXw0u+7PpEtmvJZP3pQxXuGDmpChBfP
0GPgZc/qmKJL2d5ArVoSnktp+3Sv0fI++4XAX/w2UM07v4kzSOflWcjv5Dizv79n3ObK
6DDcZT6vgAC0WSIRMzwMsErKM2tsRELOzHRnLpZU3rIlLsbQQXUYDqY7cJKQeBblO/uA
94pH07hK/SBWa6Kj1L+Abn5Dk9qnZX+Zo4xs6KSAk2zl8eORJI6CakIiTmh43hM4U5bw
KocQ/4S8nyXKBGvjTqfz+7sYgt/X4jw5tW8QZXsSWzoCDCmlFyKKov2WCrTzTIGMCz/S
07LA==
X-Gm-Message-State: ALoCoQmjwuQvBR1hv/BvhFP/q5brxb/Dp9l+hZOIx/GwfPDCVp2NWPsJb7W6yK7fv+AIqaetZuT3
MIME-Version: 1.0
X-Received: by 10.180.186.35 with SMTP id fh3mr8596067wic.7.1438278390437;
Thu, 30 Jul 2015 10:46:30 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 10:46:30 -0700 (PDT)
In-Reply-To: <CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
Date: Thu, 30 Jul 2015 19:46:30 +0200
Message-ID: <CABm2gDqC=-fvxSxCOd0s_3+iuatW54oWUPMHqW4EJ3fng-gOMw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@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] Block size following technological growth
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, 30 Jul 2015 17:46:32 -0000
On Thu, Jul 30, 2015 at 6:20 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative
When considering "too conservative" options, let's not forget that,
say, scheduling 2MB for 2020 doesn't preclude us from deciding that
was too conservative and schedule, say 4MB for 2018 later. The first
hardfork would be "useless", but it would set a "minimum increase"
that would have been useful if the second one never happened.
> I'll comment on using median time generally in Jorge's thread, but why does
> monotonically increasing matter for max block size? I can't think of a
> reason why a max block size of X bytes in block N followed by a max size of
> X-something bytes in block N+1 would cause any problems.
To be clear, for this concrete case block.nTime would just work just
fine. I just want us to decide on one of the options and uniformly
recommend that options for all cases in BIP99 [just renamed the file,
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.org ].
But, yes, please, let's discuss this in the other thread.
|
