Jacob Eliosoff [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-09 📝 Original message:I've been trying to work ...
📅 Original date posted:2017-06-09
📝 Original message: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/e606bbb0/attachment-0001.html>;
📝 Original message: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/e606bbb0/attachment-0001.html>;