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
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Yz2jT-0001Uh-HP
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 12:52:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.178 as permitted sender)
client-ip=209.85.214.178; envelope-from=gavinandresen@gmail.com;
helo=mail-ob0-f178.google.com;
Received: from mail-ob0-f178.google.com ([209.85.214.178])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yz2jS-00047I-KE
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 12:52:51 +0000
Received: by obew15 with SMTP id w15so86850038obe.1
for <bitcoin-development@lists.sourceforge.net>;
Sun, 31 May 2015 05:52:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.176.213 with SMTP id z204mr5497872oie.38.1433076765196;
Sun, 31 May 2015 05:52:45 -0700 (PDT)
Received: by 10.60.28.65 with HTTP; Sun, 31 May 2015 05:52:45 -0700 (PDT)
In-Reply-To: <CAFzgq-zTybEQyGz0nq90u5n5JZcJzxQS_XKaTpr5POJi-tHM6A@mail.gmail.com>
References: <554BE0E1.5030001@bluematt.me>
<CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
<CABsx9T0kbRe31LMwk499MQUw225f5GGd67GfhXBezHmDqxkioA@mail.gmail.com>
<CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
<CAFzgq-zTybEQyGz0nq90u5n5JZcJzxQS_XKaTpr5POJi-tHM6A@mail.gmail.com>
Date: Sun, 31 May 2015 08:52:45 -0400
Message-ID: <CABsx9T37jE3AtmUOOuW+emLGTparbS6OozPRL_hCrC+2JEzxgQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Chun Wang <1240902@gmail.com>
Content-Type: multipart/alternative; boundary=001a113c409c8688df0517602ff3
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 LOTS_OF_MONEY Huge... sums of money
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Yz2jS-00047I-KE
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2015 12:52:51 -0000
--001a113c409c8688df0517602ff3
Content-Type: text/plain; charset=UTF-8
On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail.com> wrote:
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase.
That orphan rate increase will go to whoever is producing the 20MB blocks,
NOT you.
Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
Are you sure that is the best strategy? If a big block is slow to
propagate, I suspect it will be better to punish the miner that created it
by refusing to build on it until it has been fully validated.
I'll try to find time to run a couple of simulations.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
I can benchmark it. It should be pretty fast, and sipa has a couple of
patches pending to make the UTXO cache much faster.
It can be fast because the vast majority of the work of validating all
those transactions can happen as they are received into the memory pool.
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month.
You should be able to handle 20MB blocks no problem; if I round up to 100MB
per block that works out to 1.3Mbps.
We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun.
That speed will handle 20MB blocks no problem.
If each 20MB block is 100MB of data up/down the wire (I'm vastly
over-estimating, after optimization it should be 40MB) then you'll be
paying...uhhh:
0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ /
GB = $57
Less than $2 per day in bandwidth.
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
That's OK, you'll 1.3Mbps or less.
> I think we can accept 5MB block at most.
>
Are you worried about paying too much, or do 20MB blocks "feel like too
much" ?
--
--
Gavin Andresen
--001a113c409c8688df0517602ff3
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 S=
at, May 30, 2015 at 9:31 PM, Chun Wang <span dir=3D"ltr"><<a href=3D"mai=
lto:1240902@gmail.com" target=3D"_blank">1240902@gmail.com</a>></span> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><span>
If someone propagate a 20MB block, it will take at best 6 seconds for<br>
us to receive to verify it at current configuration, result of one<br>
percent orphan rate increase.</span></blockquote><div><br></div><div>That o=
rphan rate increase will go to whoever is producing the 20MB blocks, NOT yo=
u.</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><span> Or, we can mi=
ne the next block only on<br>
the previous block's header, in this case, the network would see many<b=
r>
more transaction-less blocks.<br></span></blockquote><div><br></div><div>Ar=
e you sure that is the best strategy? If a big block is slow to propagate, =
I suspect it will be better to punish the miner that created it by refusing=
to build on it until it has been fully validated.</div><div><br></div><div=
>I'll try to find time to run a couple of simulations.</div><div><br></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><span>
<br>
Our orphan rate is about 0.5% over the past few months. If the network<br>
floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB<br>
</span>block could contain an average of 50000 transactions, hundred of<br>
<span>thousands of sigops, Do you have an estimate how long it takes on the=
<br>
submitblock rpccall?<br></span></blockquote><div><br></div><div>I can bench=
mark it. It should be pretty fast, and sipa has a couple of patches pending=
to make the UTXO cache much faster.</div><div><br></div><div>It can be fas=
t because the vast majority of the work of validating all those transaction=
s can happen as they are received into the memory pool.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><span>For references, our 30Mbps bandwidth in Beijing c=
osts us 1350 dollars<br>
per month.</span></blockquote><div><br></div><div>You should be able to han=
dle 20MB blocks no problem; if I round up to 100MB per block that works out=
to 1.3Mbps.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><span> We also use Aliyun=
and Linode cloud services for block<br>
propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for<br>
100Mbps connectivity at Aliyun.</span></blockquote><div><br></div><div>That=
speed will handle 20MB blocks no problem.</div><div><br></div><div>If each=
20MB block is 100MB of data up/down the wire (I'm vastly over-estimati=
ng, after optimization it should be 40MB) then you'll be paying...uhhh:=
</div><div><br></div><div>0.1 GB / block-data-on-wire * 144 blocks/day * 30=
.5 days/month * 0.13 $ / GB =3D $57</div><div><br></div><div>Less than $2 p=
er day in bandwidth.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span> For a si=
ngle cross-border TCP<br>
connection, it would be certainly far slower than 12.5 MB/s.</span>=C2=A0</=
blockquote><div><br></div><div>That's OK, you'll 1.3Mbps or less.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><span>
I think we can accept 5MB block at most.<br></span></blockquote><div><br></=
div><div>Are you worried about paying too much, or do 20MB blocks "fee=
l like too much" ?</div><div><br></div></div>-- <br><div>--<br>Gavin A=
ndresen<br></div>
</div></div>
--001a113c409c8688df0517602ff3--
|
