Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yz2Xk-0000xn-1l for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 12:40:44 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.42 as permitted sender) client-ip=209.85.218.42; envelope-from=gavinandresen@gmail.com; helo=mail-oi0-f42.google.com; Received: from mail-oi0-f42.google.com ([209.85.218.42]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yz2Xi-0003mf-8H for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 12:40:44 +0000 Received: by oihb142 with SMTP id b142so84626988oih.3 for ; Sun, 31 May 2015 05:40:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.214.132 with SMTP id n126mr5896952oig.75.1433076036785; Sun, 31 May 2015 05:40:36 -0700 (PDT) Received: by 10.60.28.65 with HTTP; Sun, 31 May 2015 05:40:35 -0700 (PDT) In-Reply-To: References: <554BE0E1.5030001@bluematt.me> Date: Sun, 31 May 2015 08:40:35 -0400 Message-ID: From: Gavin Andresen To: Chun Wang <1240902@gmail.com> Content-Type: multipart/alternative; boundary=001a113de8b01bdcba0517600406 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: 1Yz2Xi-0003mf-8H Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 12:40:44 -0000 --001a113de8b01bdcba0517600406 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, surely you can afford that. > 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 --001a113de8b01bdcba0517600406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, May 30, 2015 at 9:31 PM, Chun Wang <1240902@gmail.com> w= rote:
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 o= rphan rate increase will go to whoever is producing the 20MB blocks, NOT yo= u.


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.

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.

I'll try to find time to run a couple of simulations.

=C2=A0

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 t= akes on the
submitblock rpccall?

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.

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.
=C2=A0
For references, our 30Mbps bandwidth i= n Beijing costs us 1350 dollars
per month.

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.

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-estimati= ng, 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 =3D $57

Less than $2 p= er day in bandwidth, surely you can afford that.
=C2=A0
For a single cross-border TCP
connection, it would be certainly far slower than 12.5 MB/s.=C2=A0

That's OK, you'll 1.3Mbps or less.
=C2=A0
I think we can accept 5MB block at most.

Are you worried about paying too much, or do 20MB blocks "fee= l like too much" ?

--
--
Gavin Andresen
--001a113de8b01bdcba0517600406--