path: root/30/8bf13c844012eb6ae12521a5ee6092f54a457c

Return-Path: <martijn.meijering@mevs.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8D13FDBD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Dec 2015 17:01:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com
	[209.85.213.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51FECCB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Dec 2015 17:01:30 +0000 (UTC)
Received: by mail-vk0-f54.google.com with SMTP id f2so11407914vkb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Dec 2015 09:01:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=mevs-nl.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=mk6PUMOxDQzee1GiCWdLe2vE3pNxDCBKh454PgzQfiw=;
	b=nwjcOm553m275GPD3Muo+lKWusY/RBzVWA7KDjFXMmO1T+1v+/V9ap+pHoLrxbXGFB
	6/6VW9aU+CRL5121RkQ3xJZ0hXDV8q+u1ScGXP1xUr6cVJKgmPTDB7FN1pdk7+eXwaIL
	3ay/YjPOOfmQaq3CmcY0fGh0qo1z7KItq49fQy4ryRq2DV4EQHDMe4YsqZ9Mb9WwLtMP
	FkrSAgqbURfS0ALnZImfCTm74RaTPdkU02VwnVWUPTg1RtS9/mm2uMeYMyBUngOQTgiN
	95gZjazBMsQRQtBH3aJ5DNewarTwFddu2gKVjTHFQ9ibxDoYXOY+GJL4qT/ADqph/c8a
	o0Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=mk6PUMOxDQzee1GiCWdLe2vE3pNxDCBKh454PgzQfiw=;
	b=LwFQhFPLH3Z+sWDN57xxhxCyZNcgFfni304ogk4oLHqOTOI4eaLQiTETIbrbLJW4lt
	Yv6pQcQRF4FpUYxPPRztn/fmJ++W1NNBPUcfZOeekTf1Dcw8tH5wsDYDb5x7YnhURKpx
	dp9VJbqOPVIIx7RtXctYV0603o1p0Z3yXaBWM5Fca+p6pUWvthamUuk6NboGDTNhFRaM
	7iNbM7quP3Y1OWmxSRPhU3HDwS5aF5/B1FHCEfW++zUk9vTYRNLOOzNiNsPUdQXoAcgC
	RH0XXtuDQpbjPmeVbdG5XJEVWIPfNTeOWcaCSek65N3JEwXe7/y9tYH0z/akqUCymnQy
	LsnA==
X-Gm-Message-State: ALoCoQnpTxzYBFYtFT0B6aTdKhB7wejuC5+Ygpba0TBXAiy3MS6ZJziknHEujaP0T4hQDzWMCTKxizp+/NXmlmqAD2OFOJO/Xw==
MIME-Version: 1.0
X-Received: by 10.31.169.75 with SMTP id s72mr20948376vke.103.1450371690147;
	Thu, 17 Dec 2015 09:01:30 -0800 (PST)
Received: by 10.103.85.154 with HTTP; Thu, 17 Dec 2015 09:01:30 -0800 (PST)
In-Reply-To: <CAODYVYdGnA=L2tfGAVid0KogdytvRysoYaYaaftb-0QgT9otvw@mail.gmail.com>
References: <CAODYVYdGnA=L2tfGAVid0KogdytvRysoYaYaaftb-0QgT9otvw@mail.gmail.com>
Date: Thu, 17 Dec 2015 18:01:30 +0100
Message-ID: <CAODYVYeYWqJi1r94j8wUbnH9=fccsktp3N6i1+gO_kfCp3=aOQ@mail.gmail.com>
From: Martijn Meijering <martijn.meijering@mevs.nl>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11425e2c624ffa05271af988
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_05,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 20 Dec 2015 00:50:25 +0000
Cc: jgarzik@pobox.com
Subject: [bitcoin-dev] Fwd: Block size: It's economics & user preparation &
 moral hazard
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 17:01:32 -0000

--001a11425e2c624ffa05271af988
Content-Type: text/plain; charset=UTF-8

Appealing moderator's decision. If my post was off-topic, then so is the
whole thread. As for content-heavy, I made a very specific compromise
proposal that I'd like to bring to the developers attention. If this isn't
the place to do that, then I don't know what is, but I'd be happy to repost
to a different forum if you can suggest one that is more appropriate.

===


It looks as if there has been movement on both sides of this debate and the
outlines of a potential medium term truce are starting to appear. Given the
enormous amount of unrest this whole debate has caused I think it would be
highly desirable if both sides could reach an honourable compromise that's
ready to be deployed next year.

I'd like to make a compromise proposal, made up of of uncontroversial
elements of other proposals.

It is intended to achieve the following goals:

- Discourage a potentially disastrous contentious hard fork and
consequently only activate with overwhelming community support.
- Provide immediate relief on both fees and growth potential once activated.
- Provide immediate reassurance that there won't be radical growth for a
number of years without another hard fork.
- Lock in a temporary modest growth path that goes meaningfully beyond BIP
102 so we have at least a few years worth of certainty for those who want
growth.
- Be no more than a kick-the-can-down-the-road solution and do not rule
anything in or out after an interim period of a number of years.
- One-off activation vote to avoid uncertainty hanging over the market
indefinitely.
- Be as simple as possible to allow for the earliest possible deployment.
- Be as uncontroversial as possible to allow for the earliest possible
deployment.
- Do not grow much beyond 2M for at least a year because of concerns
expressed by miners at Scaling Bitcoin.
- Involve both a hard fork and a soft fork.
- Have continuous, gradual growth instead of big step functions.

It's essentially a combination of a variant of 2-4-8 (necessarily a hard
fork) and a soft fork version of Segregated Witness. The advantage of the
2-4-8 hard fork is that it is very simple and can be coded and merged very
quickly, probably in January. The SW soft fork on the other hand can
probably be activated sooner. Iherefore I'd like to see the hard fork
coded, merged and deployed first, then the soft fork merged and deployed
and then the hard fork activated provided it passes its vote. In this way
SW would be sandwiched between the deployment of an as yet inactive 2-4-8
and its activation.

It does not preclude further hard forks at any time, either before or after
the proposed compromise hard fork, although it is specifically intended to
discourage *contentious* hard forks. Non-contentious hard forks that become
possible in the light of experience gained are only to be welcomed of
course.

The details are as follows:

Hard fork with gradual growth:
- +20kb each difficulty adjustment up to 8M.
- Possibly a one-off jump to 2MB, but probably not given that SW will
likely be activated first.
- 95% activation threshold hard-coded to a period of 1000 blocks before a
one-off, fixed block ("election day").
- One month grace period, with a flag date at a fixed block height
("inauguration day") that will enable the growth mechanism supposing the
threshold was met by election day.
- Pull request ready somewhere in January.
- Merged in Q1.
- Release around May.
- Election day January 1st 2017.
- Inauguration day February 1st 2017.

Soft fork Segregated Witness:
- Deployed as already suggested by the developers, but modified to be aware
of the upcoming hard fork.
- Limited to 1MB for the witness section for the first two years after
deployment to take miner concerns into account and allow time for research
into give weak blocks and IBLT research
- Witness section size set to 1x or 2x the size of the main section of the
block after two years.

--001a11425e2c624ffa05271af988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Appealing moderator&#39;s =
decision. If my post was off-topic, then so is the whole thread. As for con=
tent-heavy, I made a very specific compromise proposal that I&#39;d like to=
 bring to the developers attention. If this isn&#39;t the place to do that,=
 then I don&#39;t know what is, but I&#39;d be happy to repost to a differe=
nt forum if you can suggest one that is more appropriate.<br></div><div dir=
=3D"ltr"><br>=3D=3D=3D<br><br><br>It looks as if there has been movement on=
 both sides of this debate and the outlines of a potential medium term truc=
e are starting to appear. Given the enormous amount of unrest this whole de=
bate has caused I think it would be highly desirable if both sides could re=
ach an honourable compromise that&#39;s ready to be deployed next year.<br>=
<br>I&#39;d like to make a compromise proposal, made up of of uncontroversi=
al elements of other proposals.<br><br>It is intended to achieve the follow=
ing goals:<br><br>- Discourage a potentially disastrous contentious hard fo=
rk and consequently only activate with overwhelming community support.<br>-=
 Provide immediate relief on both fees and growth potential once activated.=
<br>- Provide immediate reassurance that there won&#39;t be radical growth =
for a number of years without another hard fork.<br>- Lock in a temporary m=
odest growth path that goes meaningfully beyond BIP 102 so we have at least=
 a few years worth of certainty for those who want growth.<br>- Be no more =
than a kick-the-can-down-the-road solution and do not rule anything in or o=
ut after an interim period of a number of years.<br>- One-off activation vo=
te to avoid uncertainty hanging over the market indefinitely.<br>- Be as si=
mple as possible to allow for the earliest possible deployment.<br>- Be as =
uncontroversial as possible to allow for the earliest possible deployment.<=
br>- Do not grow much beyond 2M for at least a year because of concerns exp=
ressed by miners at Scaling Bitcoin.<br>- Involve both a hard fork and a so=
ft fork.<br>- Have continuous, gradual growth instead of big step functions=
.<br><br>It&#39;s essentially a combination of a variant of 2-4-8 (necessar=
ily a hard fork) and a soft fork version of Segregated Witness. The advanta=
ge of the 2-4-8 hard fork is that it is very simple and can be coded and me=
rged very quickly, probably in January. The SW soft fork on the other hand =
can probably be activated sooner. Iherefore I&#39;d like to see the hard fo=
rk coded, merged and deployed first, then the soft fork merged and deployed=
 and then the hard fork activated provided it passes its vote. In this way =
SW would be sandwiched between the deployment of an as yet inactive 2-4-8 a=
nd its activation.<br><br>It does not preclude further hard forks at any ti=
me, either before or after the proposed compromise hard fork, although it i=
s specifically intended to discourage *contentious* hard forks. Non-content=
ious hard forks that become possible in the light of experience gained are =
only to be welcomed of course.<br><br>The details are as follows:<br><br>Ha=
rd fork with gradual growth:<br>- +20kb each difficulty adjustment up to 8M=
.<br>- Possibly a one-off jump to 2MB, but probably not given that SW will =
likely be activated first.<br>- 95% activation threshold hard-coded to a pe=
riod of 1000 blocks before a one-off, fixed block (&quot;election day&quot;=
).<br>- One month grace period, with a flag date at a fixed block height (&=
quot;inauguration day&quot;) that will enable the growth mechanism supposin=
g the threshold was met by election day.<br>- Pull request ready somewhere =
in January.<br>- Merged in Q1.<br>- Release around May.<br>- Election day J=
anuary 1st 2017.<br>- Inauguration day February 1st 2017.<br><br>Soft fork =
Segregated Witness:<br>- Deployed as already suggested by the developers, b=
ut modified to be aware of the upcoming hard fork.<br>- Limited to 1MB for =
the witness section for the first two years after deployment to take miner =
concerns into account and allow time for research into give weak blocks and=
 IBLT research<br>- Witness section size set to 1x or 2x the size of the ma=
in section of the block after two years.<br></div>
</div><br></div>

--001a11425e2c624ffa05271af988--