diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2015-05-31 08:52:45 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-31 12:52:51 +0000 |
| commit | 7de44f773b3793f2663fcda99ed250e35f5d9b01 (patch) | |
| tree | f9d800552dbdac3e7682562cde9d24a1b04c86a6 | |
| parent | 46475ba696cf82d89a0048a6eab31286e1586cbf (diff) | |
| download | pi-bitcoindev-7de44f773b3793f2663fcda99ed250e35f5d9b01.tar.gz pi-bitcoindev-7de44f773b3793f2663fcda99ed250e35f5d9b01.zip | |
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
| -rw-r--r-- | 1c/cf3906ee30724d412cd912123b3847e93b0310 | 222 |
1 files changed, 222 insertions, 0 deletions
diff --git a/1c/cf3906ee30724d412cd912123b3847e93b0310 b/1c/cf3906ee30724d412cd912123b3847e93b0310 new file mode 100644 index 000000000..93cb068e5 --- /dev/null +++ b/1c/cf3906ee30724d412cd912123b3847e93b0310 @@ -0,0 +1,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-- + + |