public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jl2012@xbt•hk
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
Date: Tue, 18 Aug 2015 05:54:56 -0400	[thread overview]
Message-ID: <d17549688c0c747b2077c1f6f96b6445@xbt.hk> (raw)

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.


             reply	other threads:[~2015-08-18  9:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18  9:54 jl2012 [this message]
2015-08-18 11:57 ` Micha Bailey
2015-08-18 18:52 ` Eric Lombrozo
2015-08-18 20:48 ` Danny Thorpe
2015-08-18 20:51   ` Eric Lombrozo
2015-08-18 21:06     ` Danny Thorpe
2015-08-18 21:17       ` Eric Lombrozo
2015-08-18 21:39         ` Danny Thorpe
2015-08-19  9:29       ` Jorge Timón
2015-08-19 10:14         ` odinn
2015-08-19 11:06           ` Jorge Timón
2015-08-19 11:25             ` odinn
2015-08-19 15:22               ` jl2012
2015-08-19 15:48                 ` Tier Nolan
2015-08-19 15:25               ` Jorge Timón
2015-08-19 17:30         ` Danny Thorpe
2015-08-19 18:33           ` Jorge Timón
2015-08-18 22:51 ` Ahmed Zsales
2015-08-19  2:53   ` Eric Lombrozo
2015-08-19  9:24 ` Jorge Timón
2015-08-19 10:34   ` jl2012
2015-08-19 10:53     ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d17549688c0c747b2077c1f6f96b6445@xbt.hk \
    --to=jl2012@xbt$(echo .)hk \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox