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
128
129
130
|
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 406B94D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 15:55:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
[209.85.217.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 94435147
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 15:55:11 +0000 (UTC)
Received: by lbbpo9 with SMTP id po9so63541710lbb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 08:55:09 -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=0N/4eiNNSTeartgxZzJ6sdwsonj7Rachs/DbcEP+b7k=;
b=lMN6PuQrYmS8dk/9BXTO2kfp5VU0gnZ/HYEmiPIbrnn6rNl+4UIWy8+Eba6QENwYmp
UnABuUFQGX0e6T8ur/FF6Gg9qbuvpedYime09BOb1V4Hn3HYQyVjP6QKaYoWhKs4q4ex
Ojvr49UzXlhGhh19Y7aWoShAwC2H8rybYmSWAr+w2SVEeWf+nNoRhZSzHrdoZ01tLl5r
DPiYIuH9Gg4N2BXzGMzJFy5eljikY3Q0F9zyY/rUBpcCkZSteCniUT8YQcoqzPh3wet1
nbKb05dAeC45Tv8TCiunyJqbGRVHfqUznNXokX4RMW9QdYOJqV5wi40ImamDHl3lVAww
W3/w==
MIME-Version: 1.0
X-Received: by 10.152.115.132 with SMTP id jo4mr8254623lab.113.1438962909700;
Fri, 07 Aug 2015 08:55:09 -0700 (PDT)
Received: by 10.25.143.195 with HTTP; Fri, 7 Aug 2015 08:55:09 -0700 (PDT)
In-Reply-To: <CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
Date: Fri, 7 Aug 2015 11:55:09 -0400
Message-ID: <CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c366d213e7c9051cbaa9de
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] Fees and the block-finding process
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: Fri, 07 Aug 2015 15:55:12 -0000
--001a11c366d213e7c9051cbaa9de
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> I guess my question (and perhaps that's what Jorge is after): do you feel
> that blocks should be increased in response to (or for fear of) such a
> scenario.
>
I think there are multiple reasons to raise the maximum block size, and
yes, fear of Bad Things Happening as we run up against the 1MB limit is one
of the reasons.
I take the opinion of smart engineers who actually do resource planning and
have seen what happens when networks run out of capacity very seriously.
And if so, if that is a reason for increase now, won't it be a reason for
> an increase later as well? It is my impression that your answer is yes,
> that this is why you want to increase the block size quickly and
> significantly, but correct me if I'm wrong.
>
Sure, it might be a reason for an increase later. Here's my message to
in-the-future Bitcoin engineers: you should consider raising the maximum
block size if needed and you think the benefits of doing so (like increased
adoption or lower transaction fees or increased reliability) outweigh the
costs (like higher operating costs for full-nodes or the disruption caused
by ANY consensus rule change).
--
--
Gavin Andresen
--001a11c366d213e7c9051cbaa9de
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 F=
ri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <span dir=3D"ltr"><<a href=3D=
"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I guess my questio=
n (and perhaps that's what Jorge is after): do you feel that blocks sho=
uld be increased in response to (or for fear of) such a scenario. </div></d=
iv></div></div></blockquote><div><br></div><div>I think there are multiple =
reasons to raise the maximum block size, and yes, fear of Bad Things Happen=
ing as we run up against the 1MB limit is one of the reasons.</div><div><br=
></div><div>I take the opinion of smart engineers who actually do resource =
planning and have seen what happens when networks run out of capacity very =
seriously.</div><div><br></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>And if so, if that is a reason for increase now, won't it be a reaso=
n for an increase later as well? It is my impression that your answer is ye=
s, that this is why you want to increase the block size quickly and signifi=
cantly, but correct me if I'm wrong. <br></div></div></div></div></bloc=
kquote><div><br></div><div>Sure, it might be a reason for an increase later=
. Here's my message to in-the-future Bitcoin engineers: =C2=A0you shoul=
d consider raising the maximum block size if needed and you think the benef=
its of doing so (like increased adoption or lower transaction fees or incre=
ased reliability) outweigh the costs (like higher operating costs for full-=
nodes or the disruption caused by ANY consensus rule change).</div></div><d=
iv><br></div><div><br></div>-- <br><div class=3D"gmail_signature">--<br>Gav=
in Andresen<br></div><div class=3D"gmail_signature"><br></div>
</div></div>
--001a11c366d213e7c9051cbaa9de--
|
