From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 40A603C8 for ; Sat, 1 Aug 2015 20:45:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14C9E8F for ; Sat, 1 Aug 2015 20:45:25 +0000 (UTC) Received: by iggf3 with SMTP id f3so35821921igg.1 for ; Sat, 01 Aug 2015 13:45:24 -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=AJ3P3kJNzXtvtCOYB+yN4PTbVM6c/M66QXWIqGZVzWo=; b=tQ5euS6kE6qx351KqRsJdK2lvkq2UiitIpeDgu9KgtjWjWGFghfwtme+VNuf3E9pD+ f8nwqXvH2CVVvNWsLjKlaKeeCiVTQZ0ozqCAd8ZanvtPr18abSLp84kV3TUWQAL89OUQ nZsNdZaVEix3rmXR3o4t2YaHUZmORHjUpkHzKottLSDtbC3fa5/hHUGOiApLtygNGgN/ kRR/gkE6oOTm2b1IU+ZXkWSraYU6DmHRnx0q2hUnovADKaHEUKMYNFuvXCbmb+X9P1K9 XU4uwTqcoKRrX/R1OJCTJkbYDvdl8foTExD0GVEY4tRZObkmfX/uQUPGAf3/j3ve//bK b7RA== MIME-Version: 1.0 X-Received: by 10.50.21.10 with SMTP id r10mr15052494ige.94.1438461924507; Sat, 01 Aug 2015 13:45:24 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Sat, 1 Aug 2015 13:45:24 -0700 (PDT) In-Reply-To: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com> References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com> Date: Sat, 1 Aug 2015 22:45:24 +0200 Message-ID: From: Pieter Wuille To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=047d7b86eeae0889da051c46047b 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@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 20:45:26 -0000 --047d7b86eeae0889da051c46047b Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There is a summary of the proposals in my previous mail at > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html > 1. Initiation: BIP34 style voting, with support of 750 out of the last > 1000 blocks. The "hardfork bit" mechanism might be used: > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html > This is fine, I think. I believe we shouldn't proceed with a hardfork without having reasonable expectation that it will be deployed by everyone in time, while we can only measure miner acceptance. Still, as a belt-and-suspenders this won't hurt. > 2. Starting date: 30 days after 75% miner support, but not before > 2016-01-12 00:00 UTC > > Rationale: A 30-day grace period is given to make sure everyone has enough > time to follow. This is a compromise between 14 day in BIP101 and 1 year in > BIP103. I tend to agree with BIP101. Even 1 year is given, people will just > do it on the 364th day if they opt to procrastinate. > Given the time recent softforks have taken to deploy, I think that's too soon. 2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China. > Most pool operators and devs should be back from new year holiday and not > sleeping. (If the initiation is delayed, we may require that it must be UTC > Tuesday midnight). > That's an interesting thing to take into account. > 3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by > 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on > 2017-05-11. > > Rationale: Instead of jumping to 8MB, I suggest to increase it gradually > to 8MB in 16 months. 8MB should not be particularly painful to run even > with current equipment (you may see my earlier post on bitctointalk: > https://bitcointalk.org/index.php?topic=1054482.0). 8MB is also agreed by > Chinese miners, who control >60% of the network. > I have considered suggesting a faster ramp-up in the beginning, but I don't think there is indisputable evidence that we can currently deal with significantly larger blocks. I don't think "painful" is the right criterion either; I'm sure my equipment can "handle" 20 MB blocks too, but with a huge impact on network propagation speed, and even more people choosing the outsource their full nodes. Regarding "reasonable", I have a theory. What if we would have had 8 MB blocks from the start? My guess is that some more people would have decided to run their high-transaction-rate use cases on chain, that we'd regularly see 4-6 MB blocks, there would be more complaints about low full node counts, maybe 90% instead of 60% of the hash rate would be have SPV mining agreements with each other, we'd somehow have accepted that even worse reality, but people would still be complaining about the measly 25 transactions per second that Bitcoin could handle on-chain, and be demanding a faster rampup to a more "reasonable" 64 MB block size as well. > > 4. After 8MB is reached, the block size will be increased by 6.714% every > 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or > double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on > 2042-11-17. > > Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4% > p.a. of BIP101. This will take us almost 8 years from now just to go back > to the original 32MB size (4 years for BIP101 and 22 years for BIP103) > > SSD price is expected to drop by >50%/year in the coming years. In 2020, > we will only need to pay 2% of current price for SSD. 98% price reduction > is enough for 40 years of 27.67% growth. > Source: > http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures > I know many technologies have had faster growth, but I believe that global bandwidth accessibility is the bottleneck, so the growth rate in my proposal is based on that. > Global bandwidth is expected to grow by 37%/year until 2021 so 27.67% > should be safe at least for the coming 10 years. > Source: > https://www.telegeography.com/research-services/global-bandwidth-forecast-service/ > I'd rather be conservative here. My primary purpose is trying to create an uncontroversial proposal that introduces an expectation of growth with technology. -- Pieter --047d7b86eeae0889da051c46047b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <= span dir=3D"ltr"><bitcoin-dev@lists.linuxfoundation.org> w= rote:
There is a summary of the proposals in my previous mail = at https://lists.linuxf= oundation.org/pipermail/bitcoin-dev/2015-July/009808.html
1. Initiation: BIP34 style voting, with support of 750 out of the last 1000= blocks. The "hardfork bit" mechanism might be used: http://lists.linuxfoundation.org/pip= ermail/bitcoin-dev/2015-July/009576.html

This is fine, I think. I believe we shouldn't proceed with a hard= fork without having reasonable expectation that it will be deployed by ever= yone in time, while we can only measure miner acceptance. Still, as a belt-= and-suspenders this won't hurt.
=C2=A0
2. Starting date: 30 days after 75% miner support, but not before 2016-01-1= 2 00:00 UTC

Rationale: A 30-day grace period is given to make sure everyone has enough = time to follow. This is a compromise between 14 day in BIP101 and 1 year in= BIP103. I tend to agree with BIP101. Even 1 year is given, people will jus= t do it on the 364th day if they opt to procrastinate.

Given the time recent softforks have taken to deploy, I thi= nk that's too soon.

2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China. = Most pool operators and devs should be back from new year holiday and not s= leeping. (If the initiation is delayed, we may require that it must be UTC = Tuesday midnight).

That's an intere= sting thing to take into account.
=C2=A0
3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by = 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on 20= 17-05-11.

Rationale: Instead of jumping to 8MB, I suggest to increase it gradually to= 8MB in 16 months. 8MB should not be particularly painful to run even with = current equipment (you may see my earlier post on bitctointalk: https://bitcointalk.org/index.php?topic=3D1054482.0). 8M= B is also agreed by Chinese miners, who control >60% of the network.
=

I have considered suggesting a faster ramp= -up in the beginning, but I don't think there is indisputable evidence = that we can currently deal with significantly larger blocks. I don't th= ink "painful" is the right criterion either; I'm sure my equi= pment can "handle" 20 MB blocks too, but with a huge impact on ne= twork propagation speed, and even more people choosing the outsource their = full nodes.

Regarding "reasonable", I have a th= eory. What if we would have had 8 MB blocks from the start? My guess is tha= t some more people would have decided to run their high-transaction-rate us= e cases on chain, that we'd regularly see 4-6 MB blocks, there would be= more complaints about low full node counts, maybe 90% instead of 60% of th= e hash rate would be have SPV mining agreements with each other, we'd s= omehow have accepted that even worse reality, but people would still be com= plaining about the measly 25 transactions per second that Bitcoin could han= dle on-chain, and be demanding a faster rampup to a more "reasonable&q= uot; 64 MB block size as well.
=C2=A0
http://wikibon.org/wiki/= v/Evolution_of_All-Flash_Array_Architectures

<= /div>
I know many technologies have had faster growth, but I believe th= at global bandwidth accessibility is the bottleneck, so the growth rate in = my proposal is based on that.
=C2=A0
Global bandwidth is expected to grow by 37%/year until 2021 so 27.67% shoul= d be safe at least for the coming 10 years.
Source: https://ww= w.telegeography.com/research-services/global-bandwidth-forecast-service/

--047d7b86eeae0889da051c46047b--