Jacob Eliosoff [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-09 📝 Original message:Ah, two corrections: 1. I ...

📅 Original date posted:2017-06-09
📝 Original message: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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170609/e004899e/attachment-0001.html>;