[bitcoin-dev] The BIP148 chain split may be inevitable

[bitcoin-dev] The BIP148 chain split may be inevitable

[Jacob Eliosoff]

[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3580 bytes --]

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jacob Eliosoff]

[-- Attachment #1: Type: text/plain, Size: 3492 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4721 bytes --]

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jacob Eliosoff]

[-- Attachment #1: Type: text/plain, Size: 5848 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7835 bytes --]

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jorge Timón]

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

This is not needed, if segwit is locked in by aug 1 (with or without
bip91), no split will happen even if segwit is not active yet.
So the hashrate majority could avoid the split that way (or adopting bip148).

But it doesn't seem like they are planning to do this (with or without
bip91), the last thing I've heard, it's they will wait until
"immediately" before they signal sw (but there must be some language
barrier here, perhaps "immediately" and "inmediatamente" are false
friends). The reason why they will wait until "immediately" instead of
just starting to signal sw today, it's still unclear to me.

The other way to prevent the split is if bip148 users abort bip148
deployment, but unfortunately that seems increasingly unlikely.

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jorge Timón]

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 splitprotection'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 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.)
>

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 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
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jorge Timón]

oops s/45%/35%/

On Sun, Jun 11, 2017 at 7:11 PM, Jorge Timón <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 splitprotection'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 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.)
>>
>
> 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 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
>>>
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>