I’m 100% in favor of attempting a hard fork using a far less controversial, far less risky consensus rule change. We should stop wasting our energy arguing over stuff we don’t really know and understand and can’t predict very well - and we should especially avoid using a highly contentious change as our first hard fork deployment.
I’m also in favor of trying a small block increase before attempting any major jumps. I don’t think we should be focusing so much on long-term block size adjustment rules right now - much more critical is to develop a hard fork mechanism and to make sure we can deploy it. So something along these lines is probably a step in the right direction. > On Aug 18, 2015, at 2:54 AM, jl2012 via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > > Could we just stop the debate for a moment, and agree to a scheduled > experimental hardfork? > > Objectives (by order of importance): > > 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 > > 2. With a slight increase in block size, to collect data for future hardforks > > 3. To slightly relieve the pressure of full block, without minimal adverse > effects on network performance > > 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. > > > Proposal (parameters in ** are my recommendations but negotiable): > > 1. Today, we all agree that some kind of block size hardfork will happen on > t1=*1 June 2016* > > 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will > adopt the backup plan > > 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* > > 4. If the backup plan is adopted, we all agree that a better solution should > be found before t4=*31 Dec 2017*. > > Rationale: > > 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. > > 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 > > t3 = 30 days is chosen to make sure every full nodes have enough time to > upgrade after the actual hardfork date is confirmed > > 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 > > 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. > > 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. > > -------------------- > > If the community as a whole could agree with this experimental hardfork, we > could announce the plan on bitcoin.org 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
