summaryrefslogtreecommitdiff
path: root/ab/b2afa2484e53ed2d4d6e4259563dc2b0375e8b
blob: bcfd85728a433485a2a596ca31c677a9a686101e (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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
Return-Path: <sdaftuar@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C4A95282
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 16:41:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
	[209.85.218.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 66083ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 16:41:56 +0000 (UTC)
Received: by oibn4 with SMTP id n4so24847165oib.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=W7WEkDqfiHL7P0EL5nw0Sx0AhY/nZZQWJrqH5r0yMZk=;
	b=EeQYa0vrZ2yoj0EyO+hhko3CfPYjGRmRLNbLBjUrZRV3AoLWBk+74B2y658a6/Vefk
	k6F87GM9Wdm5MgEhWX+rrFykzNCAc9h76WbjMth/K//Sa1k8bJvN9uuQz2p55cY5mkyX
	w2h6LbWmQkGYw8ysfdVo5KgywC1CHS2mU4nDxW/DBag4DiebMXgQJT8xDDTsung1LGUG
	D3oYlEJqhWxxjdUTc+gMZogxVy6ccLIJilDtF1qGpqduhEyCWIOy9ozfZOB4bjCbbtja
	k21EzvP9peHWIDmNdkBfl6+m8BCgHUTwBFXBbnnUzDqiT2udyQlUF8VaqYQ6HsfyyNe8
	UOHw==
MIME-Version: 1.0
X-Received: by 10.202.196.18 with SMTP id u18mr41681289oif.58.1438274515850;
	Thu, 30 Jul 2015 09:41:55 -0700 (PDT)
Received: by 10.202.87.215 with HTTP; Thu, 30 Jul 2015 09:41:55 -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 12:41:55 -0400
Message-ID: <CAFp6fsExyinUm8uUiOY_xEDkYKcq09XZU3uy+YAcCyTEdeE6rA@mail.gmail.com>
From: Suhas Daftuar <sdaftuar@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113e38509b5b62051c1a6139
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 16:41:56 -0000

--001a113e38509b5b62051c1a6139
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 30, 2015 at 12:20 PM, Gavin Andresen 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, and the most likely effect of being that conservative is that
> the main blockchain becomes a settlement network, affordable only for
> large-value transactions.
>

While that may be true I think that's okay -- if it turns out that this is
too conservative, and we succeed in scaling the system so that it's
non-controversial to increase these limits later via another hard fork, we
would still be free to do so.

It seems to me that everyone who has been arguing recently to increase the
block size limit ought to find this proposal to be a strict improvement
over where we are now, and this proposal seems like it's reasonably likely
to be non-controversial enough to be worth proposing as a hard fork in
Bitcoin Core -- thank you Pieter for putting this together.

For my part, I'd give this a concept ACK, pending hearing further thoughts
from others.

Suhas Daftuar

--001a113e38509b5b62051c1a6139
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 30, 2015 at 12:20 PM, Gavin Andresen via bitcoin-dev <span dir=3D"l=
tr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><div>So we&#39;d get to 2MB blocks in the year 2021.=
 I think that is much too conservative, and the most likely effect of being=
 that conservative is that the main blockchain becomes a settlement network=
, affordable only for large-value transactions.</div></div></div></div></bl=
ockquote><div><br></div><div>While that may be true I think that&#39;s okay=
 -- if it turns out that this is too conservative, and we succeed in scalin=
g the system so that it&#39;s non-controversial to increase these limits la=
ter via another hard fork, we would still be free to do so.</div><div><br><=
/div><div>It seems to me that everyone who has been arguing recently to inc=
rease the block size limit ought to find this proposal to be a strict impro=
vement over where we are now, and this proposal seems like it&#39;s reasona=
bly likely to be non-controversial enough to be worth proposing as a hard f=
ork in Bitcoin Core -- thank you Pieter for putting this together.</div><di=
v><br></div><div>For my part, I&#39;d give this a concept ACK, pending hear=
ing further thoughts from others.</div><div><br></div><div>Suhas Daftuar</d=
iv></div></div></div>

--001a113e38509b5b62051c1a6139--