<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">People have already been testing big blocks on testnets.<div class=""><br class=""></div><div class="">The biggest problem here isn’t whether we can test the code in a fairly sterile environment. The biggest problem is convincing enough people to switch without:</div><div class=""><br class=""></div><div class="">1) Pissing off the other side enough to the point where regardless of who wins the other side refuses to cooperate</div><div class="">2) Screwing up the incentive model, allowing people to sabotage the process somehow</div><div class="">3) Setting a precedent enabling hostile entities to destroy the network from within in the future</div><div class="">etc…</div><div class=""><br class=""></div><div class="">These kinds of things seem very hard to test on a testnet.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 18, 2015, at 2:06 PM, Danny Thorpe <<a href="mailto:danny.thorpe@gmail.com" class="">danny.thorpe@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" style="font-size:12.8px" class="">Ya, so? All that means is that the experiment might reach the hard fork tipping point faster than mainnet would. Verifying that the network can handle such transitions, and how larger blocks affect the network, is the point of testing.<div class=""><br class=""></div><div class="">And when I refer to testnet, I mean the public global testnet blockchain, not in-house isolated networks like testnet-in-a-box.</div></div><div class="yj6qo ajU" style="font-size:12.8px"><div id=":of" class="ajR" tabindex="0"><img class="ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" style="opacity: 0.3;"></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <span dir="ltr" class=""><<a href="mailto:elombrozo@gmail.com" target="_blank" class="">elombrozo@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Problem is if you know most of the people running the testnet personally (as is pretty much the case with many current testnets) then the deployment amounts to “hey guys, let’s install the new version”<div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Deploying experimental code onto the "live" bitcoin blockchain seems unnecessarily risky. Why not deploy a blocksize limit experiment for long term trials using testnet instead?</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <span dir="ltr" class=""><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I understand, there is already a consensus among core dev that block size should/could be raised. The remaining questions are how, when, how much, and how fast. These are the questions for the coming Bitcoin Scalability Workshops but immediate consensus in these issues are not guaranteed.<br class="">
<br class="">
Could we just stop the debate for a moment, and agree to a scheduled experimental hardfork?<br class="">
<br class="">
Objectives (by order of importance):<br class="">
<br class="">
1. The most important objective is to show the world that reaching consensus for a Bitcoin hardfork is possible. If we could have a successful one, we would have more in the future<br class="">
<br class="">
2. With a slight increase in block size, to collect data for future hardforks<br class="">
<br class="">
3. To slightly relieve the pressure of full block, without minimal adverse effects on network performance<br class="">
<br class="">
With the objectives 1 and 2 in mind, this is to NOT intended to be a kick-the-can-down-the-road solution. The third objective is more like a side effect of this experiment.<br class="">
<br class="">
<br class="">
Proposal (parameters in ** are my recommendations but negotiable):<br class="">
<br class="">
1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016*<br class="">
<br class="">
2. If no other consensus could be reached before t2=*1 Feb 2016*, we will adopt the backup plan<br class="">
<br class="">
3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*<br class="">
<br class="">
4. If the backup plan is adopted, we all agree that a better solution should be found before t4=*31 Dec 2017*.<br class="">
<br class="">
Rationale:<br class="">
<br class="">
t1 = 1 June 2016 is chosen to make sure everyone have enough time to prepare for a hardfork. Although we do not know what actually will happen but we know something must happen around that moment.<br class="">
<br class="">
t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2 months after the workshops). If it is successful, we don't need to activate the backup plan<br class="">
<br class="">
t3 = 30 days is chosen to make sure every full nodes have enough time to upgrade after the actual hardfork date is confirmed<br class="">
<br class="">
t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate, hopefully we would find a better solution. It is important to acknowledge that the backup plan is not a final solution<br class="">
<br class="">
m = 80%: We don't want a very small portion of miners to have the power to veto a hardfork, while it is important to make sure the new fork is secured by enough mining power. 80% is just a compromise.<br class="">
<br class="">
s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all types of technology has since improved by >50%. I don't mind making it a bit smaller but in that case not much valuable data could be gathered and the second objective of this experiment may not be archived.<br class="">
<br class="">
--------------------<br class="">
<br class="">
If the community as a whole could agree with this experimental hardfork, we could announce the plan on <a href="http://bitcoin.org/" rel="noreferrer" target="_blank" class="">bitcoin.org</a> and start coding of the patch immediately. At the same time, exploration for a better solution continues. If no further consensus could be reached, a new version of Bitcoin Core with the patch will be released on or before 1 Feb 2016 and everyone will be asked to upgrade immediately.<br class="">
_______________________________________________<br class="">
bitcoin-dev mailing list<br class="">
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class="">
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank" class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">bitcoin-dev mailing list<br class=""><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class=""><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank" class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>