Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzSvT-0008O2-EH for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 16:50:59 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of coinapex.com designates 209.85.223.197 as permitted sender) client-ip=209.85.223.197; envelope-from=yifu@coinapex.com; helo=mail-ie0-f197.google.com; Received: from mail-ie0-f197.google.com ([209.85.223.197]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzSvR-0001F5-IS for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 16:50:59 +0000 Received: by ieua9 with SMTP id a9so35447868ieu.0 for ; Mon, 01 Jun 2015 09:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C1gCJrEzWno1iuYU9orC7K+BeYrwhhcr/1qgAhoGjTc=; b=Mx7/MYr9lmejUU8GQl/Y6fI3W5mnGMaeIn01BUuIu5JOOGoOHFnvxZxN06pqxNlxKi 2pyQFb4kqIBG2Qjyc/uTfzyw1CH0fQk+8mSABH5wMevlrB/Wwcw7F6LkmfVAuMumBlO3 vYqboh9zUHYAaGCXVRL1CmgFmjCm2JwnSo3PKxoTRlygYknfR//nPcjPGv8206nP4WYS t7+Vo9/5AzrOR28yrpE1OPJNWjdg4N7/nQaNZ4bl7vf8KQgPAFXNjz3lZQS6RfMP/+D1 LGJreaxL/v1p6/MZznsxy0mgRR5MXmmXW0TsGxCwo+AAziwkmv++gh627sbGlrZntfWJ sHiQ== X-Gm-Message-State: ALoCoQkhMWSdQHWrnU5Yu6sSS8tUkddqP+A94oFw9BK4EltuzMHZ06kjKQgklt0QWGgTD3uc9oZm MIME-Version: 1.0 X-Received: by 10.202.107.77 with SMTP id g74mr17957421oic.120.1433177018607; Mon, 01 Jun 2015 09:43:38 -0700 (PDT) Received: by 10.202.115.83 with HTTP; Mon, 1 Jun 2015 09:43:38 -0700 (PDT) In-Reply-To: References: <554BE0E1.5030001@bluematt.me> Date: Mon, 1 Jun 2015 12:43:38 -0400 Message-ID: From: Yifu Guo To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a11408c7e1841960517778704 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 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 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YzSvR-0001F5-IS 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: Mon, 01 Jun 2015 16:50:59 -0000 --001a11408c7e1841960517778704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nielsen's Law of Internet Bandwidth is simply not true, but if you look at data points like http://www.netindex.com/upload/ which will show we are at least on the right track, but this is flawed still. The fact of the matter is these speed tests are done from local origin to local destination within the city, let alone the country ( see note about how these test are only conducted 300 miles within the server). and our current internet infrastructure is set up with CDNs for the web and media consumption. these data points can not and should not be used to model the connectivity of a peer to peer network. Uplink bandwidth is scarce is China and expensive, avg about $37 per 1mbps after 5, but this is not the real problem. the true issue lies in the ISP transparent proxy they run. this is not a problem isolated in just China, Thailand and various other countries in Asia like Lebanon. I have also heard in various IRCs that southern France also face this similar issue due to poor routing configurations they have that prevents connections to certain parts of the world, unsure if this is a mistake or a geopolitical by-product. As for your question earlier Gavin, from Dallas TX to a VPS in Shanghai on =E4=B8=8A=E6=B5=B7=E7=94=B5=E4=BF=A1/Shanghai telecom, which is capped a= t 5mbps the data results match my concerns, I've gotten low as 83 Kbits/sec and as high as 9.24 Mbits/sec. and other ranges in between, none are consistent. ping avg is about 250ms. The temporary solution I recommend again from earlier is MPTCP: http://www.multipath-tcp.org/ which allows you to multiple interfaces/networks for a single TCP connection, this is mainly developed for mobile3g/wifi transition but I found uses to improve bandwidth and connection stability on the go by combining a local wifi/ethernet connection with my 3g phone tether. this allows you to set up a middlebox somewhere, put shadowsocks server on it, and on your local machine you can route all TCP traffic over the shadow socks client and MPTCP will automatically pick the best path for upload and download. On Mon, Jun 1, 2015 at 9:59 AM, Gavin Andresen wrote: > On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902@gmail.com> wrote: > >> I cannot believe why Gavin (who seems to have difficulty to spell my >> name correctly.) insists on his 20MB proposal regardless the >> community. BIP66 has been introduced for a long time and no one knows >> when the 95% goal can be met. This change to the block max size must >> take one year or more to be adopted. We should increase the limit and >> increase it now. 20MB is simply too big and too risky, sometimes we >> need compromise and push things forward. I agree with any solution >> lower than 10MB in its first two years. >> >> > Thanks, that's useful! > > What do other people think? Would starting at a max of 8 or 4 get > consensus? Scaling up a little less than Nielsen's Law of Internet > Bandwidth predicts for the next 20 years? (I think predictability is > REALLY important). > > I chose 20 because all of my testing shows it to be safe, and all of my > back-of-the-envelope calculations indicate the costs are reasonable. > > If consensus is "8 because more than order-of-magnitude increases are > scary" -- ok. > > -- > -- > Gavin Andresen > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --=20 *Yifu Guo* *"Life is an everlasting self-improvement."* --001a11408c7e1841960517778704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0Nielsen= 's Law of Internet Bandwidth is simply not true, but if you look at dat= a points like=C2=A0http://www.netindex.com/upload/ which will show we are at least o= n the right track, but this is flawed still.

The fact of the matter is these speed tests are done = from local origin to local destination within the city, let alone the count= ry ( see note about how these test are only conducted 300 miles within the = server). and our current internet=C2=A0infrastructure is set up with CDNs f= or the web and media consumption.
these data points can not and should not be used to mo= del the connectivity of a peer to peer network.=C2=A0

Uplink bandw= idth is scarce is China and expensive, avg about $37 per 1mbps after 5, but= this is not the real problem. the true issue lies in the ISP=C2=A0transpar= ent proxy they run. this is not a problem isolated in just China, Thailand = and various other countries in Asia like Lebanon. I have also heard in vari= ous IRCs that southern France also face this similar issue due to poor rout= ing configurations they have that prevents connections to certain parts of = the world, unsure if this is a mistake or a geopolitical by-product.
<= div>
As for your question earlier Gavin, from Dallas TX to a = VPS in Shanghai on=C2=A0=E4=B8=8A=E6=B5=B7=E7=94=B5=E4=BF=A1/Shanghai telec= om, which is capped at 5mbps the data results match my concerns, I've g= otten low as 83 Kbits/sec and as high as=C2=A09.24 Mbits/sec. and other ran= ges in between, none are consistent. ping avg is about 250ms.
=



On Mon, Jun 1, 2015 at 9:59 AM, Gavin Andresen <g= avinandresen@gmail.com> wrote:
= On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902@gmail.= com> wrote:
I cannot believ= e why Gavin (who seems to have difficulty to spell my
name correctly.) insists on his 20MB proposal regardless the
community. BIP66 has been introduced for a long time and no one knows
when the 95% goal can be met. This change to the block max size must
take one year or more to be adopted. We should increase the limit and
increase it now. 20MB is simply too big and too risky, sometimes we
need compromise and push things forward. I agree with any solution
lower than 10MB in its first two years.


=
Thanks, that's useful!

What do oth= er people think?=C2=A0 Would starting at a max of 8 or 4 get consensus?=C2= =A0 Scaling up a little less than Nielsen's Law of Internet Bandwidth p= redicts for the next 20 years? =C2=A0(I think predictability is REALLY impo= rtant).

I chose 20 because all of my testing shows= it to be safe, and all of my back-of-the-envelope calculations indicate th= e costs are reasonable.

If consensus is "8 be= cause more than order-of-magnitude increases are scary" -- ok.

--
--
Gavin Andresen

-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--
Yifu Guo
= "Life is an everlasting self-improvement."
--001a11408c7e1841960517778704--