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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 736364A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 16:49:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9CE4110A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 16:49:53 +0000 (UTC)
Received: by ioii16 with SMTP id i16so59649571ioi.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 09:49:53 -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=VjUx52X4e3lM0b11kPwkv4B3uPZbryG4dndVVAE0Jp0=;
b=kz/yAWf28mXk5N5atUtse3Jf/V27p5eDUi7fAEjzG3TGCZ22r1jU7/dSkcXpZ/jIVJ
3f1jOwlrr7v+m/zW9M9hmcn60RSwrII3VgC2QhEHs4SVMQqy7eAZ246aaMl1tyzELZ48
mjuX8JfGIsfnWhYK+gt0PP+oHxR3faNp8Y0RM3H/8Ih/GR4QV3hGoU/dJfWfJMhk9Q/V
o9y5muKbqBDcUYbJ0xsyPiwqndt7tRUKxGvcunQTg/O8ClSeb2LQ02byKfcOox0+pOPD
3TUsW8TnJ4YiFuVT/Q0x6udm+dR7YFzvFRSugWXSFlSj+WFns6VUobvJLRZLOyaAFUmr
Oung==
MIME-Version: 1.0
X-Received: by 10.107.9.137 with SMTP id 9mr12486315ioj.50.1438274993030; Thu,
30 Jul 2015 09:49:53 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 09:49:52 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 09:49:52 -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 18:49:52 +0200
Message-ID: <CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f8f140c8ff2051c1a7e84
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:49:54 -0000
--001a113f8f140c8ff2051c1a7e84
Content-Type: text/plain; charset=UTF-8
On Jul 30, 2015 6:20 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> 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!
You're welcome.
> 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.
If there is demand for high-value settlements in Bitcoin, and this results
in a functioning economy where fees support the security of a transparent
network, I think that would be a much better outcome than what we have now.
> 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.
Well, centralization of mining is already terrible. I see no reason why we
should encourage making it worse. On the other hand, sure, not every
transaction fits on the blockchain. That is already the case, and will
remain the case with 2 MB or 8 MB or 100 MB blocks. Some use cases fit, and
others won't. We need to accept that, and all previous proposals I've seen
don't seem to do that.
Maybe the only ones that will fit are large settlements between layer-2
services, and maybe it will be something entirely different. But at least
we don't need to compromise the security of the main layer, or promise the
ecosystem unrealistic growth of space for on-chain transactions.
If Bitcoin needs to support a large scale, it already failed.
> 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.
I don't think it matters much, but it offers slightly easier transition for
the mempool (something Jorge convinced me of), and validation can benefit
from a single variable that can be set in a chain to indicate a switchover
happened, without needing to recalculate it every time.
I assume you're asking this because using raw nTime means you can check
what limits a p2p message should obey to by looking at just the first
bytes. I don't think this matters: your p2p protocol should deal with
whatever limits the system requires anyway. An attacker can take a valid
message of far in the chain, change a few bytes, and spam you with it at
zero extra effort anyway.
--
Pieter
--001a113f8f140c8ff2051c1a7e84
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Jul 30, 2015 6:20 PM, "Gavin Andresen" <<a href=3D"mailto:g=
avinandresen@gmail.com">gavinandresen@gmail.com</a>> wrote:<br>
><br>
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>> wrote:<br>
>><br>
>> Some things are not included yet, such as a testnet whose size run=
s ahead of the main chain, and the inclusion of Gavin's more accurate s=
igop checking after the hard fork.<br>
>><br>
>> Comments?<br>
><br>
><br>
> First, THANK YOU for making a concrete proposal!</p>
<p dir=3D"ltr">You're welcome.</p>
<p dir=3D"ltr">> Specific comments:<br>
><br>
> So we'd get to 2MB blocks in the year 2021. I think that is much t=
oo conservative, and the most likely effect of being that conservative is t=
hat the main blockchain becomes a settlement network, affordable only for l=
arge-value transactions.</p>
<p dir=3D"ltr">If there is demand for high-value settlements in Bitcoin, an=
d this results in a functioning economy where fees support the security of =
a transparent network, I think that would be a much better outcome than wha=
t we have now.</p>
<p dir=3D"ltr">> I don't think your proposal strikes the right balan=
ce between centralization of payments (a future where only people running p=
ayment hubs, big merchants, exchanges, and wallet providers settle on the b=
lockchain) and centralization of mining.</p>
<p dir=3D"ltr">Well, centralization of mining is already terrible. I see no=
reason why we should encourage making it worse. On the other hand, sure, n=
ot every transaction fits on the blockchain. That is already the case, and =
will remain the case with 2 MB or 8 MB or 100 MB blocks. Some use cases fit=
, and others won't. We need to accept that, and all previous proposals =
I've seen don't seem to do that.</p>
<p dir=3D"ltr">Maybe the only ones that will fit are large settlements betw=
een layer-2 services, and maybe it will be something entirely different. Bu=
t at least we don't need to compromise the security of the main layer, =
or promise the ecosystem unrealistic growth of space for on-chain transacti=
ons.</p>
<p dir=3D"ltr">If Bitcoin needs to support a large scale, it already failed=
.</p>
<p dir=3D"ltr">> I'll comment on using median time generally in Jorg=
e'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 bloc=
k N followed by a max size of X-something bytes in block N+1 would cause an=
y problems.</p>
<p dir=3D"ltr">I don't think it matters much, but it offers slightly ea=
sier transition for the mempool (something Jorge convinced me of), and vali=
dation can benefit from a single variable that can be set in a chain to ind=
icate a switchover happened, without needing to recalculate it every time.<=
/p>
<p dir=3D"ltr">I assume you're asking this because using raw nTime mean=
s you can check what limits a p2p message should obey to by looking at just=
the first bytes. I don't think this matters: your p2p protocol should =
deal with whatever limits the system requires anyway. An attacker can take =
a valid message of far in the chain, change a few bytes, and spam you with =
it at zero extra effort anyway.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--001a113f8f140c8ff2051c1a7e84--
|
