From: Danny Thorpe <danny.thorpe@gmail.com>
To: jl2012@xbt.hk
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
Date: Tue, 18 Aug 2015 13:48:49 -0700 [thread overview]
Message-ID: <CAJN5wHV-qyOcEw5spQc74nT7_b29WMiDTmi4Jj0ri_rGCQz2ng@mail.gmail.com> (raw)
In-Reply-To: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 3677 bytes --]
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?
On Tue, 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
>
[-- Attachment #2: Type: text/html, Size: 4358 bytes --]
next prev parent reply other threads:[~2015-08-18 20:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 9:54 [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork? jl2012
2015-08-18 11:57 ` Micha Bailey
2015-08-18 18:52 ` Eric Lombrozo
2015-08-18 20:48 ` Danny Thorpe [this message]
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=CAJN5wHV-qyOcEw5spQc74nT7_b29WMiDTmi4Jj0ri_rGCQz2ng@mail.gmail.com \
--to=danny.thorpe@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jl2012@xbt.hk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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