oops s/45%/35%/
On Sun, Jun 11, 2017 at 7:11 PM, Jorge Timón <jti...@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.elios...@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.elios...@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 >> _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
