Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7ACBB98C for ; 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 ; Fri, 9 Jun 2017 05:23:20 +0000 (UTC) Received: by mail-lf0-f50.google.com with SMTP id p189so25476071lfe.2 for ; 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: References: From: Jacob Eliosoff Date: Fri, 9 Jun 2017 01:23:17 -0400 Message-ID: To: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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&#= 39;t require segwit *activation*, just orphans non-segwit-*signaling* (bit = 1) blocks from Aug 1.

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 "a few days ago" as I = claimed.=C2=A0 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:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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 a= ctivation) and the BIP148 UASF [4].=C2=A0 Some of this is subtle so CORRECT= IONS WELCOME, but my conclusions are:
1. It's extremely unlik= ely BIP91-type logic can activate segwit in time to avoid a BIP148 chain sp= lit.
2. So, in practice all we can do is ensure the BIP148 split = is as painless as possible.

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's rough exp= ected next four difficulty adjustment dates (they could vary by ~1-3 days d= epending 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.=C2=A0 So, working backwards, and assuming we want= compatibility with old BIP141 nodes:

- Segwit MUS= T 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 hashpow= er needs to be BIP91 miners, signaling bit 1 and orphaning non-BIP91 (ie, B= IP91'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)<= /div>
- Therefore, >=3D80% of hashrate must start signaling BIP91= 9;s bit 4 by a few days ago...

There are ways part= s of this could be sped up, eg, James' "rolling 100-block lock-in = periods" [5], to get BIP91 signaling bit 1 sooner.=C2=A0 But to be com= patible with old BIP141 nodes, >50% of hashrate must be activated BIP91 = miners by ~June 30: there's no fudging that.

S= o, it seems to me that to avoid the BIP148 split, one of two things would h= ave to happen:
a) 95% of hashrate start signaling bit 1 by ~June = 30.=C2=A0 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.=C2=A0 Again, much t= oo soon.

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.


--001a1140134cbe73290551802af5--