MIME-Version: 1.0
In-Reply-To: <CABm2gDp8Dvi1eLOOU9E04OvVZR5U1=6bn9vf9k8=di66eg2EQA@mail.gmail.com>
References: <CAAUaCygRaXNX5xWuka1xrrXwKv1tqevT9-cHd-5mh_AkHpg9gA@mail.gmail.com>
	<CAAUaCyh_uBcZ7ntbLtOeOAK-6nt2Rx-cxx27QaiXRKkije21AQ@mail.gmail.com>
	<CAAUaCyiwnspvJ9HY41GK8tMsA4ezpFPR1Ka9upik6UwsYBASnQ@mail.gmail.com>
	<CABm2gDp8Dvi1eLOOU9E04OvVZR5U1=6bn9vf9k8=di66eg2EQA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sun, 11 Jun 2017 19:12:35 +0200
Message-ID: <CABm2gDpy8XA3Nh+amYMb4GamOy+FdjwSGc19X6HtNJg2YkNH0w@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The BIP148 chain split may be inevitable
Precedence: list

oops s/45%/35%/

On Sun, Jun 11, 2017 at 7:11 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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:
>> - Of course the 80% threshold could just be reduced, eg to splitprotecti=
on's
>> 65%
>
> This still doesn't prevent the split if 45% or more of the hashrate
> keeps blocking segwit, so I don't see how this help.
>
>> - BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
>> lock-in, rather than waiting another period until it  "activates".
>
> Miners could start signaling bit 1 today, before they use bip91 too
> and signal bit 4 in addition.
> But they aren't doing it, it seems they prefer to block segwit. I
> don't see why changing using bit 4 or reducing the threshold would
> change their mind.
>
>> THE BAD NEWS: no one should underestimate the steps that would need to b=
e
>> 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 min=
er
>> 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.)
>>
>
> Or you can replace this whole plan with the step 3, convincing miners
> to stop blocking segwit, upgrade to segwit capable code if they
> haven't already and signal bit 1 to activate it.
> If you don't get that, there's going to be a split. Unless bip148 is
> aborted in favor of bip149, which seems unlikely.
>
> If we had 51%+ of the hashrate currently signaling segwit, I believe
> there would be no problem convincing people to move from bip148 to
> bip91, but we don't have that.
>
> To me the lesson is not rushed deployments but bip8 and never commit
> the mistake of giving miners the ability to block changes again, like
> we did with csv and segwit, but using bip8 instead of bip9 from now
> on.
>
>> [1] See Saicere's comment:
>> https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and relat=
ed
>> discussion at
>> https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.
>>
>> [2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 node=
s
>> 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 ~J=
uly
>>> 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.c=
om>
>>> wrote:
>>>>
>>>> I've been trying to work out the expected interaction between James
>>>> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which b=
oth
>>>> use variants of BIP91 activation) and the BIP148 UASF [4].  Some of th=
is is
>>>> subtle so CORRECTIONS WELCOME, but my conclusions are:
>>>> 1. It's extremely unlikely BIP91-type logic can activate segwit in tim=
e
>>>> 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-segwi=
t
>>>> blocks on midnight (GMT) the morning of August 1.  Meanwhile, here are
>>>> Bitcoin's rough expected next four difficulty adjustment dates (they c=
ould
>>>> vary by ~1-3 days depending on block times, but it's unlikely to matte=
r
>>>> 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 l=
ate
>>>> to avoid BIP148's split, which will have occurred the moment August be=
gan.
>>>> So, working backwards, and assuming we want compatibility with old BIP=
141
>>>> 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 activa=
te),
>>>> by adj #2 (June 30)?
>>>> - Therefore, as currently designed, BIP91 bit 4 must be locked in by a=
dj
>>>> #1 (June 17)
>>>> - Therefore, >=3D80% 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 activate=
d
>>>> 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 s=
tat
>>>> 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 fe=
w
>>>> parts of the ecosystem will join the fork, so disruption will be beara=
ble.
>>>> 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/0145=
08.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
>>>
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>