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
115
116
117
118
119
120
121
122
123
124
125
126
127
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 75FEE4A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 16:20:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com
[209.85.215.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D66C2214
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 16:20:31 +0000 (UTC)
Received: by lagw2 with SMTP id w2so28290274lag.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 09:20:30 -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=aQjv0cvXKPJot52bFV16+lfYpUvw/96318SZ2D6r5dI=;
b=vkckuRSbFP1YvfVMZ79g8Db/zXjKULEgRrusxirkSoGo19bCYTA9V5BHgzvuY7Bzo0
AQjZeFTYF28UNT2+qxuxyVwweuvA/0uvemPNGKVnPL0ipQ/6yEK8pdE9otCSKxtoB0eB
RNwAVNEDAOwthZmEaDpEsJD9qgZzbY+Q5+TPymGesebUtPfTOSraeXZrvGAGSWP8eCMz
N1KJE6KPoCwbol93o/HVM79c6BKLCHCoydHHoJIqQaRb/gX2KxjlpJ8/NLaEwA8S9N9Y
AON56h3lCmwf3ThF3MJbJQmNELpn+fnsw9j/37GgekkUgy3Wa5yIdYa4qFDiNMYQS5Y6
g2WQ==
MIME-Version: 1.0
X-Received: by 10.112.199.133 with SMTP id jk5mr46261958lbc.32.1438273230104;
Thu, 30 Jul 2015 09:20:30 -0700 (PDT)
Received: by 10.25.18.228 with HTTP; Thu, 30 Jul 2015 09:20:30 -0700 (PDT)
In-Reply-To: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
Date: Thu, 30 Jul 2015 12:20:30 -0400
Message-ID: <CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c264bef87130051c1a14f7
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:20:32 -0000
--001a11c264bef87130051c1a14f7
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Some things are not included yet, such as a testnet whose size runs ahead
> of the main chain, and the inclusion of Gavin's more accurate sigop
> checking after the hard fork.
>
> Comments?
>
First, THANK YOU for making a concrete proposal!
Specific comments:
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.
I don't think your proposal strikes the right balance between
centralization of payments (a future where only people running payment
hubs, big merchants, exchanges, and wallet providers settle on the
blockchain) and centralization of mining.
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.
--
--
Gavin Andresen
--001a11c264bef87130051c1a14f7
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 10:25 AM, Pieter Wuille via bitcoin-dev <span dir=3D"lt=
r"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div><div>Some things are not includ=
ed yet, such as a testnet whose size runs ahead of the main chain, and the =
inclusion of Gavin's more accurate sigop checking after the hard fork.<=
br><br></div>Comments?<span class=3D"HOEnZb"><font color=3D"#888888"><br></=
font></span></div></div></blockquote><div><br></div><div>First, THANK YOU f=
or making a concrete proposal!</div><div><br></div><div>Specific comments:<=
/div><div><br></div><div>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 th=
at conservative is that the main blockchain becomes a settlement network, a=
ffordable only for large-value transactions.</div><div><br></div><div>I don=
't think your proposal strikes the right balance between centralization=
of payments (a future where only people running payment hubs, big merchant=
s, exchanges, and wallet providers settle on the blockchain) and centraliza=
tion of mining.</div><div><br></div><div><br></div><div><br></div><div>I=
9;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 si=
ze of X-something bytes in block N+1 would cause any problems.</div></div><=
div><br></div>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br=
></div>
</div></div>
--001a11c264bef87130051c1a14f7--
|
