<div dir="ltr">On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is a summary of the proposals in my previous mail at <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html</a><br>
1. Initiation: BIP34 style voting, with support of 750 out of the last 1000 blocks. The &quot;hardfork bit&quot; mechanism might be used: <a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html" rel="noreferrer" target="_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html</a><br></blockquote><div><br></div><div>This is fine, I think. I believe we shouldn&#39;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&#39;t hurt.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Starting date: 30 days after 75% miner support, but not before 2016-01-12 00:00 UTC<br>
<br>
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.<br></blockquote><div><br></div><div>Given the time recent softforks have taken to deploy, I think that&#39;s too soon.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br></blockquote><div><br></div><div>That&#39;s an interesting thing to take into account. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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: <a href="https://bitcointalk.org/index.php?topic=1054482.0" rel="noreferrer" target="_blank">https://bitcointalk.org/index.php?topic=1054482.0</a>). 8MB is also agreed by Chinese miners, who control &gt;60% of the network.<br></blockquote><div><br></div><div>I have considered suggesting a faster ramp-up in the beginning, but I don&#39;t think there is indisputable evidence that we can currently deal with significantly larger blocks. I don&#39;t think &quot;painful&quot; is the right criterion either; I&#39;m sure my equipment can &quot;handle&quot; 20 MB blocks too, but with a huge impact on network propagation speed, and even more people choosing the outsource their full nodes.<br><br></div><div>Regarding &quot;reasonable&quot;, 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&#39;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&#39;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 &quot;reasonable&quot; 64 MB block size as well.<br></div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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)<br>
<br>
SSD price is expected to drop by &gt;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.<br>
Source: <a href="http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures" rel="noreferrer" target="_blank">http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures</a><br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Global bandwidth is expected to grow by 37%/year until 2021 so 27.67% should be safe at least for the coming 10 years.<br>
Source: <a href="https://www.telegeography.com/research-services/global-bandwidth-forecast-service/" rel="noreferrer" target="_blank">https://www.telegeography.com/research-services/global-bandwidth-forecast-service/</a><br></blockquote><div><br></div><div>I&#39;d rather be conservative here. My primary purpose is trying to create an uncontroversial proposal that introduces an expectation of growth with technology.<br><br>-- <br></div><div>Pieter<br><br></div></div></div></div>