summaryrefslogtreecommitdiff
path: root/e5/daef950b9a27a1385a200a4cb31d25dcec9131
blob: cf3c265cb744460f13dcee285de5838948d1bf0e (plain)
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.