path: root/e7/ba77e0089ffacdc486be32384380f6fc6a1b2b

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 752F3957
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Jun 2017 18:04:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com
	[209.85.215.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1649512A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Jun 2017 18:04:35 +0000 (UTC)
Received: by mail-lf0-f46.google.com with SMTP id v20so39199374lfa.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Jun 2017 11:04:34 -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=9dzuA9VbNnNGi+nCccNAaCpkTqXE1t9kjVdKDbnkiOw=;
	b=oEdkJS4TfbprBhxyNy0m5J9h8MzMSHpQz0WrxJ/KPYtojhW7otEpvVU2uF4U5fev4D
	g8qqOh+Oz8fSOd/rEfeWgWO+8C3fBGN+fFJfJrU/WWz7j6iejaZ6EL5y0R4eKpUlYOuo
	irzwo061xNt1xdzChZhJuQ70N/fxuf06qYlbq3T7v2F1fBJenhyQDg7mAJOHuRUmRQB9
	OZOMl9VaXBQmyuhdMPNT2afqjjNpQXn4+1sYPgoDt0Z1tBrnf24iInNu/QPuPVasiqY/
	B/JpFpyu31VJHrf0pOzoPtF8mr9GUrKumc0RlGkD7xRwIrIKyVqhgP24PyXh07lDcz6B
	Aj5g==
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=9dzuA9VbNnNGi+nCccNAaCpkTqXE1t9kjVdKDbnkiOw=;
	b=sjIY1TydqrUovFtzYfB5OWHSdHeGGYsBkotqG/tKMafSFYmS9kS/N0pXNJecZIbP9i
	KtxkHshrvOuTIfvaLIKiWCEvIJOnUMCnCrWZZ3bCEnmV0xuOL8wNQEjeB5cmOlQlVXU8
	IhI/JcqcST4+2uBz3ZYl04ooT+Dozc4apAD+MuRdc43H1LTKe/sDBBISZI3Ys3WvMQSK
	JnPNQA5qoUvib2vv7+1EcHYF77O18/BXBD1qvw74XeYcYPXwFwnDYq9DXvjXvo085SWG
	uSjgp6cO0UkZEkCbrprf4idY4eMVOgIUY/c1EZsgCN+Tn7413QKFYMeDBm23d9EhHfri
	SeFQ==
X-Gm-Message-State: AODbwcB2WXq1r73BTgxjAk2+GUM2VvtXLrJN+Sw8PC3sCiMkh3JScT26
	rsJcgbD4HfkjwqJ16CyFAuBdRcC7R6HYJ6g=
X-Received: by 10.25.37.209 with SMTP id l200mr14433410lfl.156.1497117873026; 
	Sat, 10 Jun 2017 11:04:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.22 with HTTP; Sat, 10 Jun 2017 11:04:32 -0700 (PDT)
In-Reply-To: <CAAUaCyh_uBcZ7ntbLtOeOAK-6nt2Rx-cxx27QaiXRKkije21AQ@mail.gmail.com>
References: <CAAUaCygRaXNX5xWuka1xrrXwKv1tqevT9-cHd-5mh_AkHpg9gA@mail.gmail.com>
	<CAAUaCyh_uBcZ7ntbLtOeOAK-6nt2Rx-cxx27QaiXRKkije21AQ@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Sat, 10 Jun 2017 14:04:32 -0400
Message-ID: <CAAUaCyiwnspvJ9HY41GK8tMsA4ezpFPR1Ka9upik6UwsYBASnQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a11403a6a023fa305519eeb1c"
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: Sat, 10 Jun 2017 19:18:12 +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: Sat, 10 Jun 2017 18:04:36 -0000

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

Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
split, because I may have left an overly pessimistic impression -

In short: the timing isn't as dire as I suggested, BUT unless concrete
progress on a plan starts taking shape, esp miner support, *the split is
indeed coming.*

THE GOOD NEWS: several refinements have been noted which could get BIP91
(or splitprotection, Segwit2x, etc) deployed faster:
- The lock-in window could be shortened, eg to splitprotection's 504 blocks
(3.5 days)
- Of course the 80% threshold could just be reduced, eg to
splitprotection's 65%
- BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
lock-in, rather than waiting another period until it  "activates".
 (Orphaning of non-bit-1-signaling blocks would probably also have to start
at or shortly after the same time [1].)

Combining these approaches, *July 26* is an approximate hard deadline for
>50% of miners to be running BIP91 in order to prevent the split.  So,
significantly less tight than my previous June 30 (or my original,
erroneous "a few days ago").

THE BAD NEWS: no one should underestimate the steps that would need to be
completed by that deadline:
1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148
itself, ...)
2. Implement and test it
3. Convince >50% of miners to run it [2]
4. Miners upgrade to the new software and begin signaling

In particular, #3: afaict a lot of convincing is still needed before miner
support for any of these reaches anything like 50%.  (With the exception of
Segwit2x, but it has the additional handicap that it probably needs to
include deployable hard fork code, obviously ambitious in 1.5 months.)


[1] See Saicere's comment:
https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and related
discussion at https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011
.

[2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodes
signaling segwit support do *not* count, since they won't orphan non-bit-1
blocks.  The impending split isn't between nodes that support segwit vs
don't, but between those that reject non-segwit-supporting blocks vs don't.


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

> 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
>>
>
>

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

<div dir=3D"ltr">Just a quick follow-up on BIP91&#39;s prospects of avoidin=
g a BIP148 chain split, because I may have left an overly pessimistic impre=
ssion -<div><br></div><div>In short: the timing isn&#39;t as dire as I sugg=
ested, BUT unless concrete progress on a plan starts taking shape, esp mine=
r support, *the split is indeed coming.*<div><br></div><div>THE GOOD NEWS: =
several refinements have been noted which could get BIP91 (or splitprotecti=
on, Segwit2x, etc)=C2=A0deployed faster:</div><div>- The lock-in window cou=
ld be shortened, eg to splitprotection&#39;s 504 blocks (3.5 days)<br></div=
><div>- Of course the 80% threshold could just be reduced, eg to splitprote=
ction&#39;s 65%</div><div>- BIP91 nodes could start signaling on bit 1 the =
moment bit 4 reaches lock-in, rather than waiting another period until it =
=C2=A0&quot;activates&quot;. =C2=A0(Orphaning of non-bit-1-signaling blocks=
 would probably also have to start at or shortly after the same time [1].)<=
br></div><div><br></div><div>Combining these approaches, *July 26* is an ap=
proximate hard deadline for &gt;50% of miners to be running BIP91 in order =
to prevent the split.=C2=A0 So, significantly less tight than my previous J=
une 30 (or my original, erroneous &quot;a few days ago&quot;).</div><div><b=
r></div><div>THE BAD NEWS: no one should underestimate the steps that would=
 need to be completed by that deadline:</div><div>1. Coordinate on a soluti=
on (BIP91, splitprotection, Segwit2x, BIP148 itself, ...)</div><div>2. Impl=
ement and test it</div><div>3. Convince &gt;50% of miners to run it [2]</di=
v><div>4. Miners upgrade to the new software and begin signaling</div><div>=
<br></div><div>In particular, #3: afaict a lot of convincing is still neede=
d before miner support for any of these reaches anything like 50%. =C2=A0(W=
ith the exception of Segwit2x, but it has the additional handicap that it p=
robably needs to include deployable hard fork code, obviously ambitious in =
1.5 months.)</div><div><br></div><div><br></div><div>[1] See Saicere&#39;s =
comment:=C2=A0<a href=3D"https://github.com/btc1/bitcoin/pull/11#discussion=
_r121086886">https://github.com/btc1/bitcoin/pull/11#discussion_r121086886<=
/a>, and related discussion at=C2=A0<a href=3D"https://github.com/btc1/bitc=
oin/pull/11#issuecomment-307330011">https://github.com/btc1/bitcoin/pull/11=
#issuecomment-307330011</a>.</div><div><br></div><div>[2] Note that &gt;50%=
 need to run the *solution*, eg BIP91; old BIP141 nodes signaling segwit su=
pport do *not* count, since they won&#39;t orphan non-bit-1 blocks.=C2=A0 T=
he impending split isn&#39;t between nodes that support segwit vs don&#39;t=
, but between those that reject non-segwit-supporting blocks vs don&#39;t.<=
/div><div><div><br></div></div></div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Fri, Jun 9, 2017 at 1:23 AM, Jacob Eliosoff <s=
pan 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;padd=
ing-left:1ex"><div dir=3D"ltr">Ah, two corrections:<div>1. I meant to inclu=
de an option c): of course &gt;50% of hashpower running BIP148 by Aug 1 avo=
ids a split.</div><div>2. More seriously, I misrepresented BIP148&#39;s log=
ic: it doesn&#39;t require segwit *activation*, just orphans non-segwit-*si=
gnaling* (bit 1) blocks from Aug 1.<div><br></div><div>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 &quot;a few days a=
go&quot; as I claimed.=C2=A0 So, tight timing, but not impossible.<div><br>=
</div></div><div>Sorry about the errors.</div><div><br></div></div></div><d=
iv class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div c=
lass=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"_blan=
k">jacob.eliosoff@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>I&#39;ve been trying to work out the expecte=
d interaction between James Hilliard&#39;s BIP91 [1] (or splitprotection [2=
], or Segwit2x [3], which both use variants of BIP91 activation) and the BI=
P148 UASF [4].=C2=A0 Some of this is subtle so CORRECTIONS WELCOME, but my =
conclusions are:</div><div>1. It&#39;s extremely unlikely BIP91-type logic =
can activate segwit in time to avoid a BIP148 chain split.</div><div>2. So,=
 in practice all we can do is ensure the BIP148 split is as painless as pos=
sible.</div><div><br></div><div>REASONING: =C2=A0First, some dates.=C2=A0 B=
IP148, whose deadline is already deployed and thus unlikely to be postponed=
, starts orphaning non-segwit blocks on midnight (GMT) the morning of Augus=
t 1.=C2=A0 Meanwhile, here are Bitcoin&#39;s rough expected next four diffi=
culty adjustment dates (they could vary by ~1-3 days depending on block tim=
es, 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</div><div><br></div><di=
v>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 be=
gan.=C2=A0 So, working backwards, and assuming we want compatibility with o=
ld BIP141 nodes:</div><div><br></div><div>- Segwit MUST 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 node=
s)</div><div>- Therefore, I *think* &gt;50% of hashpower needs to be BIP91 =
miners, signaling bit 1 and orphaning non-BIP91 (ie, BIP91&#39;s bit 4 must=
 activate), by adj #2 (June 30)?</div><div>- Therefore, as currently design=
ed, BIP91 bit 4 must be locked in by adj #1 (June 17)</div><div>- Therefore=
, &gt;=3D80% of hashrate must start signaling BIP91&#39;s bit 4 by a few da=
ys ago...</div><div><br></div><div>There are ways parts of this could be sp=
ed 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 compatible with old BIP1=
41 nodes, &gt;50% of hashrate must be activated BIP91 miners by ~June 30: t=
here&#39;s no fudging that.</div><div><br></div><div>So, it seems to me tha=
t to avoid the BIP148 split, one of two things would have to happen:</div><=
div>a) 95% of hashrate start signaling bit 1 by ~June 30.=C2=A0 Given curre=
nt stat is 32%, this would basically require magic.</div><div>b) BIP91 is d=
eployed and &gt;50% (80% or whatever) of hashrate is *activated* BIP91 mine=
rs by ~June 30, ~3 weeks from now.=C2=A0 Again, much too soon.</div><div><b=
r></div><div>So, I think the BIP148 split is inevitable.=C2=A0 I actually e=
xpect that few parts of the ecosystem will join the fork, so disruption wil=
l be bearable.=C2=A0 But anyway let me know any flaws in the reasoning abov=
e.</div><div><br></div><div>[1] <a href=3D"https://github.com/bitcoin/bips/=
blob/master/bip-0091.mediawiki" target=3D"_blank">https://github.com/bitcoi=
n/bip<wbr>s/blob/master/bip-0091.mediawi<wbr>ki</a></div><div>[2] <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/01450=
8.html" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/pipermail/=
bitcoin-dev/2017<wbr>-June/014508.html</a></div><div>[3] <a href=3D"https:/=
/github.com/btc1/bitcoin/pull/11" target=3D"_blank">https://github.com/btc1=
/bitcoi<wbr>n/pull/11</a></div><div>[4] <a href=3D"https://github.com/bitco=
in/bips/blob/master/bip-0148.mediawiki" target=3D"_blank">https://github.co=
m/bitcoin/bip<wbr>s/blob/master/bip-0148.mediawi<wbr>ki</a></div><div>[5] <=
a href=3D"https://github.com/btc1/bitcoin/pull/6#issuecomment-305917729" ta=
rget=3D"_blank">https://github.com/btc1/bitcoi<wbr>n/pull/6#issuecomment-30=
591772<wbr>9</a></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a11403a6a023fa305519eeb1c--