MIME-Version: 1.0
In-Reply-To: <CAK_HAC-QmFiQGePpPH7n7qV-A4mkQdsWmgwA__mc1GBkTa6oFA@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
	<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
	<9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
	<CAK_HAC-QmFiQGePpPH7n7qV-A4mkQdsWmgwA__mc1GBkTa6oFA@mail.gmail.com>
Date: Thu, 17 Dec 2015 14:09:05 +0100
Message-ID: <CABm2gDp+UFua=ZqzDFhZ7F6MeLbc_fBv13WYcpttSP1Lyy1ngg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Corey Haddad <corey3@gmail.com>
Content-Type: multipart/alternative; boundary=001a11408b143bd659052717ba7e
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling
	Bitcoin
Precedence: list

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

Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
than 6 months for a hardfork is starting to push it too much.
For a more complex hardfork (say, a SW hardfork or a collection of many
little fixes) I believe 1 year or more would make more sense.

BIP99 recommends a time threshold (height or median time) + 95% miner
upgrade confirmation with BIP9 (version bits).
So how about the following plan?

1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade
confirmation

2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9.

Note that both "when it's ready" depend on something we are not paying a
lot of attention to: bip9's implementation (just like bip113, bip68-112,
bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork,
etc).

Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
equivalent to the 2-4-8 "compromise" proposal (which by the way I never
liked, because I don't think anybody should be in a position to
"compromise" anything and because I don't see how "let's avoid an
unavoidable economic change for a little bit longer" arguments can
reasoably claim that "we need to kick the can down the road exactly 3 more
times" or whatever is the reasoning behind it).

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

<p dir=3D"ltr">Although I agree that how safe a pre-hardfork upgrade period=
 is depends on the complexity of the changes (we should assume everyone may=
 need time to reimplementat it themselves in their own implementations, not=
 just upgrade bitcoin core) and bip102 is indeed a very simple hardfork, I =
think less than 6 months for a hardfork is starting to push it too much.<br=
>
For a more complex hardfork (say, a SW hardfork or a collection of many lit=
tle fixes) I believe 1 year or more would make more sense.</p>
<p dir=3D"ltr">BIP99 recommends a time threshold (height or median time) + =
95% miner upgrade confirmation with BIP9 (version bits).<br>
So how about the following plan?</p>
<p dir=3D"ltr">1) Deploy BIP102 when its ready + 6 median time months + 95%=
 miner upgrade confirmation</p>
<p dir=3D"ltr">2) Deploy SW when it&#39;s ready + 95% miner upgrade confirm=
ation via bip9.</p>
<p dir=3D"ltr">Note that both &quot;when it&#39;s ready&quot; depend on som=
ething we are not paying a lot of attention to: bip9&#39;s implementation (=
just like bip113, bip68-112, bip99, the coinbase-commitments-cleanup post-S=
W uncontroversial hardfork, etc).</p>
<p dir=3D"ltr">Unless I&#39;m missing something, 2 mb x4 =3D 8mb, so bip102=
 + SW is already equivalent to the 2-4-8 &quot;compromise&quot; proposal (w=
hich by the way I never liked, because I don&#39;t think anybody should be =
in a position to &quot;compromise&quot; anything and because I don&#39;t se=
e how &quot;let&#39;s avoid an unavoidable economic change for a little bit=
 longer&quot; arguments can reasoably claim that &quot;we need to kick the =
can down the road exactly 3 more times&quot; or whatever is the reasoning b=
ehind it).</p>

--001a11408b143bd659052717ba7e--