From: Jacob Eliosoff <jacob.eliosoff@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] The BIP148 chain split may be inevitable
Date: Fri, 9 Jun 2017 01:23:17 -0400 [thread overview]
Message-ID: <CAAUaCyh_uBcZ7ntbLtOeOAK-6nt2Rx-cxx27QaiXRKkije21AQ@mail.gmail.com> (raw)
In-Reply-To: <CAAUaCygRaXNX5xWuka1xrrXwKv1tqevT9-cHd-5mh_AkHpg9gA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2017-06-09 5:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 4:40 Jacob Eliosoff
2017-06-09 5:23 ` Jacob Eliosoff [this message]
2017-06-10 18:04 ` Jacob Eliosoff
2017-06-11 15:06 ` Jorge Timón
2017-06-11 17:11 ` Jorge Timón
2017-06-11 17:12 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAUaCyh_uBcZ7ntbLtOeOAK-6nt2Rx-cxx27QaiXRKkije21AQ@mail.gmail.com \
--to=jacob.eliosoff@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox