I've been trying to work out the expected interaction between JamesHilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which bothuse variants of BIP91 activation) and the BIP148 UASF [4]. Some of this issubtle so CORRECTIONS WELCOME, but my conclusions are:1. It's extremely unlikely BIP91-type logic can activate segwit in time toavoid a BIP148 chain split.2. So, in practice all we can do is ensure the BIP148 split is as painlessas possible.

REASONING: First, some dates. BIP148, whose deadline is already deployedand thus unlikely to be postponed, starts orphaning non-segwit blocks onmidnight (GMT) the morning of August 1. Meanwhile, here are Bitcoin'srough 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 172. June 303. July 134. July 27

If Segwit activates on adj date #5 or later (August), it will be too lateto avoid BIP148's split, which will have occurred the moment August began.So, working backwards, and assuming we want compatibility with old BIP141nodes:

- Segwit MUST activate by adj #4 (~July 27)- Therefore segwit MUST be locked in by adj #3 (~July 13: this isinflexible, 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 fewdays ago...

There are ways parts of this could be sped up, eg, James' "rolling100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. Butto be compatible with old BIP141 nodes, >50% of hashrate must be activatedBIP91 miners by ~June 30: there's no fudging that.

So, it seems to me that to avoid the BIP148 split, one of two things wouldhave to happen:a) 95% of hashrate start signaling bit 1 by ~June 30. Given current statis 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 fewparts of the ecosystem will join the fork, so disruption will be bearable.But anyway let me know any flaws in the reasoning above.

Ah, two corrections:1. I meant to include an option c): of course >50% of hashpower runningBIP148 by Aug 1 avoids a split.2. More seriously, I misrepresented BIP148's logic: it doesn't requiresegwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocksfrom 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 ~July27), not "a few days ago" as I claimed. So, tight timing, but notimpossible.

Sorry about the errors.

Post by Jacob Eliosoff via bitcoin-devI've been trying to work out the expected interaction between JamesHilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which bothuse variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is1. It's extremely unlikely BIP91-type logic can activate segwit in time toavoid a BIP148 chain split.2. So, in practice all we can do is ensure the BIP148 split is as painlessas possible.REASONING: First, some dates. BIP148, whose deadline is already deployedand thus unlikely to be postponed, starts orphaning non-segwit blocks onmidnight (GMT) the morning of August 1. Meanwhile, here are Bitcoin'srough expected next four difficulty adjustment dates (they could vary by1. June 172. June 303. July 134. July 27If Segwit activates on adj date #5 or later (August), it will be too lateto avoid BIP148's split, which will have occurred the moment August began.So, working backwards, and assuming we want compatibility with old BIP141- Segwit MUST activate by adj #4 (~July 27)- Therefore segwit MUST be locked in by adj #3 (~July 13: this isinflexible, 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 fewdays ago...There are ways parts of this could be sped up, eg, James' "rolling100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. Butto be compatible with old BIP141 nodes, >50% of hashrate must be activatedBIP91 miners by ~June 30: there's no fudging that.So, it seems to me that to avoid the BIP148 split, one of two things woulda) 95% of hashrate start signaling bit 1 by ~June 30. Given current statis 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 fewparts 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

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

In short: the timing isn't as dire as I suggested, BUT unless concreteprogress on a plan starts taking shape, esp miner support, *the split isindeed 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 tosplitprotection's 65%- BIP91 nodes could start signaling on bit 1 the moment bit 4 reacheslock-in, rather than waiting another period until it "activates".(Orphaning of non-bit-1-signaling blocks would probably also have to startat 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 becompleted by that deadline:1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148itself, ...)2. Implement and test it3. 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 minersupport for any of these reaches anything like 50%. (With the exception ofSegwit2x, but it has the additional handicap that it probably needs toinclude 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 relateddiscussion at https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.

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

1. I meant to include an option c): of course >50% of hashpower runningBIP148 by Aug 1 avoids a split.2. More seriously, I misrepresented BIP148's logic: it doesn't requiresegwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocksfrom 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 ~July27), not "a few days ago" as I claimed. So, tight timing, but notimpossible.Sorry about the errors.

Post by Jacob Eliosoff via bitcoin-devI've been trying to work out the expected interaction between JamesHilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which bothuse variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is1. It's extremely unlikely BIP91-type logic can activate segwit in timeto avoid a BIP148 chain split.2. So, in practice all we can do is ensure the BIP148 split is aspainless as possible.REASONING: First, some dates. BIP148, whose deadline is alreadydeployed and thus unlikely to be postponed, starts orphaning non-segwitblocks on midnight (GMT) the morning of August 1. Meanwhile, here areBitcoin's rough expected next four difficulty adjustment dates (they couldvary by ~1-3 days depending on block times, but it's unlikely to matter1. June 172. June 303. July 134. July 27If Segwit activates on adj date #5 or later (August), it will be too lateto avoid BIP148's split, which will have occurred the moment August began.So, working backwards, and assuming we want compatibility with old BIP141- Segwit MUST activate by adj #4 (~July 27)- Therefore segwit MUST be locked in by adj #3 (~July 13: this isinflexible, 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 afew days ago...There are ways parts of this could be sped up, eg, James' "rolling100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. Butto be compatible with old BIP141 nodes, >50% of hashrate must be activatedBIP91 miners by ~June 30: there's no fudging that.So, it seems to me that to avoid the BIP148 split, one of two thingsa) 95% of hashrate start signaling bit 1 by ~June 30. Given current statis 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 toosoon.So, I think the BIP148 split is inevitable. I actually expect that fewparts 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

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 withoutbip91), 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 withoutbip91), the last thing I've heard, it's they will wait until"immediately" before they signal sw (but there must be some languagebarrier here, perhaps "immediately" and "inmediatamente" are falsefriends). The reason why they will wait until "immediately" instead ofjust starting to signal sw today, it's still unclear to me.

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

Post by Jacob Eliosoff via bitcoin-devJust a quick follow-up on BIP91's prospects of avoiding a BIP148 chainsplit, because I may have left an overly pessimistic impression -In short: the timing isn't as dire as I suggested, BUT unless concreteprogress on a plan starts taking shape, esp miner support, *the split isindeed coming.*THE GOOD NEWS: several refinements have been noted which could get BIP91 (or- Of course the 80% threshold could just be reduced, eg to splitprotection's65%

This still doesn't prevent the split if 45% or more of the hashratekeeps blocking segwit, so I don't see how this help.

Miners could start signaling bit 1 today, before they use bip91 tooand signal bit 4 in addition.But they aren't doing it, it seems they prefer to block segwit. Idon't see why changing using bit 4 or reducing the threshold wouldchange their mind.

Post by Jacob Eliosoff via bitcoin-devTHE BAD NEWS: no one should underestimate the steps that would need to be1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148itself, ...)2. Implement and test it3. Convince >50% of miners to run it [2]4. Miners upgrade to the new software and begin signalingIn particular, #3: afaict a lot of convincing is still needed before minersupport for any of these reaches anything like 50%. (With the exception ofSegwit2x, but it has the additional handicap that it probably needs toinclude deployable hard fork code, obviously ambitious in 1.5 months.)

Or you can replace this whole plan with the step 3, convincing minersto stop blocking segwit, upgrade to segwit capable code if theyhaven't already and signal bit 1 to activate it.If you don't get that, there's going to be a split. Unless bip148 isaborted in favor of bip149, which seems unlikely.

If we had 51%+ of the hashrate currently signaling segwit, I believethere would be no problem convincing people to move from bip148 tobip91, but we don't have that.

To me the lesson is not rushed deployments but bip8 and never committhe mistake of giving miners the ability to block changes again, likewe did with csv and segwit, but using bip8 instead of bip9 from nowon.

Post by Jacob Eliosoff via bitcoin-devhttps://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and relateddiscussion athttps://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.[2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodessignaling segwit support do *not* count, since they won't orphan non-bit-1blocks. The impending split isn't between nodes that support segwit vsdon't, but between those that reject non-segwit-supporting blocks vs don't.

Post by Jacob Eliosoff via bitcoin-dev1. I meant to include an option c): of course >50% of hashpower runningBIP148 by Aug 1 avoids a split.2. More seriously, I misrepresented BIP148's logic: it doesn't requiresegwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks fromAug 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 ~July27), not "a few days ago" as I claimed. So, tight timing, but notimpossible.Sorry about the errors.

Post by Jacob Eliosoff via bitcoin-devI've been trying to work out the expected interaction between JamesHilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which bothuse variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is1. It's extremely unlikely BIP91-type logic can activate segwit in timeto avoid a BIP148 chain split.2. So, in practice all we can do is ensure the BIP148 split is aspainless as possible.REASONING: First, some dates. BIP148, whose deadline is alreadydeployed and thus unlikely to be postponed, starts orphaning non-segwitblocks on midnight (GMT) the morning of August 1. Meanwhile, here areBitcoin's rough expected next four difficulty adjustment dates (they couldvary by ~1-3 days depending on block times, but it's unlikely to matter1. June 172. June 303. July 134. July 27If Segwit activates on adj date #5 or later (August), it will be too lateto avoid BIP148's split, which will have occurred the moment August began.So, working backwards, and assuming we want compatibility with old BIP141- Segwit MUST activate by adj #4 (~July 27)- Therefore segwit MUST be locked in by adj #3 (~July 13: this isinflexible, 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 afew days ago...There are ways parts of this could be sped up, eg, James' "rolling100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. But tobe compatible with old BIP141 nodes, >50% of hashrate must be activatedBIP91 miners by ~June 30: there's no fudging that.So, it seems to me that to avoid the BIP148 split, one of two thingsa) 95% of hashrate start signaling bit 1 by ~June 30. Given current statis 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 toosoon.So, I think the BIP148 split is inevitable. I actually expect that fewparts 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

Post by Jacob Eliosoff via bitcoin-devJust a quick follow-up on BIP91's prospects of avoiding a BIP148 chainsplit, because I may have left an overly pessimistic impression -In short: the timing isn't as dire as I suggested, BUT unless concreteprogress on a plan starts taking shape, esp miner support, *the split isindeed coming.*THE GOOD NEWS: several refinements have been noted which could get BIP91 (or- Of course the 80% threshold could just be reduced, eg to splitprotection's65%

This still doesn't prevent the split if 45% or more of the hashratekeeps blocking segwit, so I don't see how this help.

Miners could start signaling bit 1 today, before they use bip91 tooand signal bit 4 in addition.But they aren't doing it, it seems they prefer to block segwit. Idon't see why changing using bit 4 or reducing the threshold wouldchange their mind.

Post by Jacob Eliosoff via bitcoin-devTHE BAD NEWS: no one should underestimate the steps that would need to be1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148itself, ...)2. Implement and test it3. Convince >50% of miners to run it [2]4. Miners upgrade to the new software and begin signalingIn particular, #3: afaict a lot of convincing is still needed before minersupport for any of these reaches anything like 50%. (With the exception ofSegwit2x, but it has the additional handicap that it probably needs toinclude deployable hard fork code, obviously ambitious in 1.5 months.)

Or you can replace this whole plan with the step 3, convincing minersto stop blocking segwit, upgrade to segwit capable code if theyhaven't already and signal bit 1 to activate it.If you don't get that, there's going to be a split. Unless bip148 isaborted in favor of bip149, which seems unlikely.If we had 51%+ of the hashrate currently signaling segwit, I believethere would be no problem convincing people to move from bip148 tobip91, but we don't have that.To me the lesson is not rushed deployments but bip8 and never committhe mistake of giving miners the ability to block changes again, likewe did with csv and segwit, but using bip8 instead of bip9 from nowon.

Post by Jacob Eliosoff via bitcoin-devhttps://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and relateddiscussion athttps://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.[2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodessignaling segwit support do *not* count, since they won't orphan non-bit-1blocks. The impending split isn't between nodes that support segwit vsdon't, but between those that reject non-segwit-supporting blocks vs don't.

Post by Jacob Eliosoff via bitcoin-dev1. I meant to include an option c): of course >50% of hashpower runningBIP148 by Aug 1 avoids a split.2. More seriously, I misrepresented BIP148's logic: it doesn't requiresegwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks fromAug 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 ~July27), not "a few days ago" as I claimed. So, tight timing, but notimpossible.Sorry about the errors.

Post by Jacob Eliosoff via bitcoin-devI've been trying to work out the expected interaction between JamesHilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which bothuse variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is1. It's extremely unlikely BIP91-type logic can activate segwit in timeto avoid a BIP148 chain split.2. So, in practice all we can do is ensure the BIP148 split is aspainless as possible.REASONING: First, some dates. BIP148, whose deadline is alreadydeployed and thus unlikely to be postponed, starts orphaning non-segwitblocks on midnight (GMT) the morning of August 1. Meanwhile, here areBitcoin's rough expected next four difficulty adjustment dates (they couldvary by ~1-3 days depending on block times, but it's unlikely to matter1. June 172. June 303. July 134. July 27If Segwit activates on adj date #5 or later (August), it will be too lateto avoid BIP148's split, which will have occurred the moment August began.So, working backwards, and assuming we want compatibility with old BIP141- Segwit MUST activate by adj #4 (~July 27)- Therefore segwit MUST be locked in by adj #3 (~July 13: this isinflexible, 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 afew days ago...There are ways parts of this could be sped up, eg, James' "rolling100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. But tobe compatible with old BIP141 nodes, >50% of hashrate must be activatedBIP91 miners by ~June 30: there's no fudging that.So, it seems to me that to avoid the BIP148 split, one of two thingsa) 95% of hashrate start signaling bit 1 by ~June 30. Given current statis 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 toosoon.So, I think the BIP148 split is inevitable. I actually expect that fewparts 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