Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-11 📝 Original message:oops s/45%/35%/ On Sun, ...

📅 Original date posted:2017-06-11
📝 Original message:oops s/45%/35%/

On Sun, Jun 11, 2017 at 7:11 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
> <bitcoin-dev at 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.eliosoff at 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.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
>>>
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>