path: root/c2/2ce8974d256d29ac25e2757e211a4f0030409d

Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7ACBB98C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 05:23:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com
	[209.85.215.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C8CC88
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 05:23:20 +0000 (UTC)
Received: by mail-lf0-f50.google.com with SMTP id p189so25476071lfe.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 08 Jun 2017 22:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=nzb3bpG8LO3sXkS+vuv2/cPogXAm7qdr5eQkEr3ePbc=;
	b=AWSflcMhHPZxVyxz0hysRLUUXBuaYoelmStRZ3q2qdK//rebWvJAOrVov8atn/YDm5
	53HjCeCP+WEMQTgZrXm22cGiVg1lMeiqMxupopLp+jiuFxbtC1jnzARvFYqoYn1UH+nF
	sR07OdCCyIGDLN68mB+N2M3JZ0ZxxEyrVyc4evIZUBAWueGcI1mGFK9rtsaxeb05CJ58
	2Te9d95l3Fd156im7M2HRr9D2EG0HEC2eLEy3pjCTV1U559DmEd6kIo0ZRCpydPnDE4Y
	mY081o6atJpacIIuSvR0J2rkvU+zY3AnQZsWlspMxZ/RDXnuaYjWqA1t7dK1dZvq2hae
	DWmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=nzb3bpG8LO3sXkS+vuv2/cPogXAm7qdr5eQkEr3ePbc=;
	b=NNplStuavDnwqpAgaZEOe68jQCCfUe67pwdlaKdyFhvIroG2KCer+nG1y7Y/FGOJYP
	cZj62bfNv/XqHlueoBKuSYpJfAE0v72UwPcE5i6LdVj5/RfbFWvXpoHxXufUrC7nLc3j
	RiW5YiP+Opi468qNts35klzaM9OXL3nYHSXhnhwtT+2EcriMjBThSZN/1JtqXVPWf+uw
	vkoq+oIKbaiMu56Wgdc+aUdxdx7tTe58yRrtp2ak7MRFtoL/vXmIUXToA5F1CzTOC+cq
	YNCGvaptzLS4JwPDzPa36EJCrbDQ0GrOygyHfPqDF5JCDeQNK6L5RiWDky/WCDiTpgwW
	UBjA==
X-Gm-Message-State: AODbwcAzBzSCjSPjwA0S4QQIK3DH5XjcA975XqhPJEeK9QyjSZser3DF
	u9yug7SMs203GiLOmdVsLLLbjGj4kavqH4U=
X-Received: by 10.25.153.203 with SMTP id b194mr252387lfe.70.1496985798339;
	Thu, 08 Jun 2017 22:23:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.22 with HTTP; Thu, 8 Jun 2017 22:23:17 -0700 (PDT)
In-Reply-To: <CAAUaCygRaXNX5xWuka1xrrXwKv1tqevT9-cHd-5mh_AkHpg9gA@mail.gmail.com>
References: <CAAUaCygRaXNX5xWuka1xrrXwKv1tqevT9-cHd-5mh_AkHpg9gA@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Fri, 9 Jun 2017 01:23:17 -0400
Message-ID: <CAAUaCyh_uBcZ7ntbLtOeOAK-6nt2Rx-cxx27QaiXRKkije21AQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1140134cbe73290551802af5"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Fri, 09 Jun 2017 06:48:18 +0000
Subject: Re: [bitcoin-dev] The BIP148 chain split may be inevitable
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 09 Jun 2017 05:23:21 -0000

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

Ah, two corrections:
1. I meant to include an option c): of course >50% of hashpower running
BIP148 by Aug 1 avoids a split.
2. More seriously, I misrepresented BIP148's logic: it doesn't require
segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks
from Aug 1.

I believe that means 80% of hashrate would need to be running BIP91
(signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
27), not "a few days ago" as I claimed.  So, tight timing, but not
impossible.

Sorry about the errors.


On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff <jacob.eliosoff@gmail.com>
wrote:

> I've been trying to work out the expected interaction between James
> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
> use variants of BIP91 activation) and the BIP148 UASF [4].  Some of this is
> subtle so CORRECTIONS WELCOME, but my conclusions are:
> 1. It's extremely unlikely BIP91-type logic can activate segwit in time to
> avoid a BIP148 chain split.
> 2. So, in practice all we can do is ensure the BIP148 split is as painless
> as possible.
>
> REASONING:  First, some dates.  BIP148, whose deadline is already deployed
> and thus unlikely to be postponed, starts orphaning non-segwit blocks on
> midnight (GMT) the morning of August 1.  Meanwhile, here are Bitcoin's
> rough expected next four difficulty adjustment dates (they could vary by
> ~1-3 days depending on block times, but it's unlikely to matter here):
> 1. June 17
> 2. June 30
> 3. July 13
> 4. July 27
>
> If Segwit activates on adj date #5 or later (August), it will be too late
> to avoid BIP148's split, which will have occurred the moment August began.
> So, working backwards, and assuming we want compatibility with old BIP141
> nodes:
>
> - Segwit MUST activate by adj #4 (~July 27)
> - Therefore segwit MUST be locked in by adj #3 (~July 13: this is
> inflexible, since this logic is in already-deployed BIP141 nodes)
> - Therefore, I *think* >50% of hashpower needs to be BIP91 miners,
> signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activate),
> by adj #2 (June 30)?
> - Therefore, as currently designed, BIP91 bit 4 must be locked in by adj
> #1 (June 17)
> - Therefore, >=80% of hashrate must start signaling BIP91's bit 4 by a few
> days ago...
>
> There are ways parts of this could be sped up, eg, James' "rolling
> 100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner.  But
> to be compatible with old BIP141 nodes, >50% of hashrate must be activated
> BIP91 miners by ~June 30: there's no fudging that.
>
> So, it seems to me that to avoid the BIP148 split, one of two things would
> have to happen:
> a) 95% of hashrate start signaling bit 1 by ~June 30.  Given current stat
> is 32%, this would basically require magic.
> b) BIP91 is deployed and >50% (80% or whatever) of hashrate is *activated*
> BIP91 miners by ~June 30, ~3 weeks from now.  Again, much too soon.
>
> So, I think the BIP148 split is inevitable.  I actually expect that few
> parts of the ecosystem will join the fork, so disruption will be bearable.
> But anyway let me know any flaws in the reasoning above.
>
> [1] https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-June/014508.html
> [3] https://github.com/btc1/bitcoin/pull/11
> [4] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> [5] https://github.com/btc1/bitcoin/pull/6#issuecomment-305917729
>

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

<div dir=3D"ltr">Ah, two corrections:<div>1. I meant to include an option c=
): of course &gt;50% of hashpower running BIP148 by Aug 1 avoids a split.</=
div><div>2. More seriously, I misrepresented BIP148&#39;s logic: it doesn&#=
39;t require segwit *activation*, just orphans non-segwit-*signaling* (bit =
1) blocks from Aug 1.<div><br></div><div>I believe that means 80% of hashra=
te would need to be running BIP91 (signaling bit 4) by ~June 30 (so BIP91 l=
ocks in ~July 13, activates ~July 27), not &quot;a few days ago&quot; as I =
claimed.=C2=A0 So, tight timing, but not impossible.<div><br></div></div><d=
iv>Sorry about the errors.</div><div><br></div></div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Fri, Jun 9, 2017 at 12:40 AM, =
Jacob Eliosoff <span dir=3D"ltr">&lt;<a href=3D"mailto:jacob.eliosoff@gmail=
.com" target=3D"_blank">jacob.eliosoff@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I&#39;ve been trying to=
 work out the expected interaction between James Hilliard&#39;s BIP91 [1] (=
or splitprotection [2], or Segwit2x [3], which both use variants of BIP91 a=
ctivation) and the BIP148 UASF [4].=C2=A0 Some of this is subtle so CORRECT=
IONS WELCOME, but my conclusions are:</div><div>1. It&#39;s extremely unlik=
ely BIP91-type logic can activate segwit in time to avoid a BIP148 chain sp=
lit.</div><div>2. So, in practice all we can do is ensure the BIP148 split =
is as painless as possible.</div><div><br></div><div>REASONING: =C2=A0First=
, some dates.=C2=A0 BIP148, whose deadline is already deployed and thus unl=
ikely to be postponed, starts orphaning non-segwit blocks on midnight (GMT)=
 the morning of August 1.=C2=A0 Meanwhile, here are Bitcoin&#39;s rough exp=
ected next four difficulty adjustment dates (they could vary by ~1-3 days d=
epending on block times, but it&#39;s unlikely to matter here):</div><div>1=
. June 17</div><div>2. June 30</div><div>3. July 13</div><div>4. July 27</d=
iv><div><br></div><div>If Segwit activates on adj date #5 or later (August)=
, it will be too late to avoid BIP148&#39;s split, which will have occurred=
 the moment August began.=C2=A0 So, working backwards, and assuming we want=
 compatibility with old BIP141 nodes:</div><div><br></div><div>- Segwit MUS=
T activate by adj #4 (~July 27)</div><div>- Therefore segwit MUST be locked=
 in by adj #3 (~July 13: this is inflexible, since this logic is in already=
-deployed BIP141 nodes)</div><div>- Therefore, I *think* &gt;50% of hashpow=
er needs to be BIP91 miners, signaling bit 1 and orphaning non-BIP91 (ie, B=
IP91&#39;s bit 4 must activate), by adj #2 (June 30)?</div><div>- Therefore=
, as currently designed, BIP91 bit 4 must be locked in by adj #1 (June 17)<=
/div><div>- Therefore, &gt;=3D80% of hashrate must start signaling BIP91&#3=
9;s bit 4 by a few days ago...</div><div><br></div><div>There are ways part=
s of this could be sped up, eg, James&#39; &quot;rolling 100-block lock-in =
periods&quot; [5], to get BIP91 signaling bit 1 sooner.=C2=A0 But to be com=
patible with old BIP141 nodes, &gt;50% of hashrate must be activated BIP91 =
miners by ~June 30: there&#39;s no fudging that.</div><div><br></div><div>S=
o, it seems to me that to avoid the BIP148 split, one of two things would h=
ave to happen:</div><div>a) 95% of hashrate start signaling bit 1 by ~June =
30.=C2=A0 Given current stat is 32%, this would basically require magic.</d=
iv><div>b) BIP91 is deployed and &gt;50% (80% or whatever) of hashrate is *=
activated* BIP91 miners by ~June 30, ~3 weeks from now.=C2=A0 Again, much t=
oo soon.</div><div><br></div><div>So, I think the BIP148 split is inevitabl=
e.=C2=A0 I actually expect that few parts of the ecosystem will join the fo=
rk, so disruption will be bearable.=C2=A0 But anyway let me know any flaws =
in the reasoning above.</div><div><br></div><div>[1] <a href=3D"https://git=
hub.com/bitcoin/bips/blob/master/bip-0091.mediawiki" target=3D"_blank">http=
s://github.com/bitcoin/<wbr>bips/blob/master/bip-0091.<wbr>mediawiki</a></d=
iv><div>[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2017-June/014508.html" target=3D"_blank">https://lists.linuxfoundation.=
<wbr>org/pipermail/bitcoin-dev/<wbr>2017-June/014508.html</a></div><div>[3]=
 <a href=3D"https://github.com/btc1/bitcoin/pull/11" target=3D"_blank">http=
s://github.com/btc1/<wbr>bitcoin/pull/11</a></div><div>[4] <a href=3D"https=
://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki" target=3D"_blank=
">https://github.com/bitcoin/<wbr>bips/blob/master/bip-0148.<wbr>mediawiki<=
/a></div><div>[5] <a href=3D"https://github.com/btc1/bitcoin/pull/6#issueco=
mment-305917729" target=3D"_blank">https://github.com/btc1/<wbr>bitcoin/pul=
l/6#issuecomment-<wbr>305917729</a></div></div>
</blockquote></div><br></div>

--001a1140134cbe73290551802af5--