From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E5055723 for ; Sun, 11 Jun 2017 17:12:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05C88185 for ; Sun, 11 Jun 2017 17:12:36 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id g66so41323643vki.1 for ; Sun, 11 Jun 2017 10:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xG+Zs2pOQa6QxGImrh/Ovt7XO1XQ9FhD70TN2Bmf2cg=; b=egw+IpuLO73DlwEAQJJhdpFnbcQtKL/o1wBEdIy9DmzDqsi+UVzLPrrfEdBAWWIsUi JEq6VEfjPukykCpKUl2BIMY4XwfdLfQo3kuLhxUy3Jow9eWI/k9mgOOFyk8n081J2oAw ECQVkM817MW3F0JmtBgVSl8+1RpunfByshw2cAqFH7XSubIuPtnhl3AQODpYr4tmjZsi Iu7/zD9BjR/KmbaR1xVOhICVEqRU3cW1gUSUiDvBZrb2phMrf+KqZ7kAtXP5mkb7Kp0M Xr1U+xgN72+GLU+ot0oteVoAizG9FgovJN/9zZNVZjoSavRIUR1obBAwINmlOcEs5KfK QGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xG+Zs2pOQa6QxGImrh/Ovt7XO1XQ9FhD70TN2Bmf2cg=; b=V5/LrWBr3Q7rKDz8LtefDl14Cp8pd2bYrQKKbi657xunnQlWe/0BVhJw/5/kUy3mLO wr/PGp1OJmOdtAY3O0RQqCppOCGHFrmkCi87/PLzdZrB7fzZxth4QMzfRVBrSZ24fSw1 ticqfPD6wcR4VPJNql1T4fx3HOrGIsLskIuyLK+SB+MDQ1LTH8ZS41BQHXCnSl2bSZTs k6E8eOxr21Zl/6xRWQcDd5+x69p2AIL9qhyljyv5LU7z6SjEWkcjbyDYYg+ozhS2KvYx DcAJhgWfcAL2MUXA0k+ms1tkdWzX6jIXSr8Oi9YA5eWNB9b+55MZVGlR98GeSHqQFw8p I0sQ== X-Gm-Message-State: AODbwcBglCXKg0oZR38pFAWp0LjPGZ31rqtCtG+idaukuz+5t4xd+xSr qxGSnDZPZ1E/7IuumEuCbzW6AbggHA2E X-Received: by 10.31.36.19 with SMTP id k19mr25863087vkk.78.1497201156015; Sun, 11 Jun 2017 10:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.52.213 with HTTP; Sun, 11 Jun 2017 10:12:35 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Sun, 11 Jun 2017 19:12:35 +0200 Message-ID: To: Jacob Eliosoff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] The BIP148 chain split may be inevitable X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 17:12:38 -0000 oops s/45%/35%/ On Sun, Jun 11, 2017 at 7:11 PM, Jorge Tim=C3=B3n wrote: > On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev > 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 splitprotecti= on'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 b= e >> 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 min= er >> 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 relat= ed >> discussion at >> https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011. >> >> [2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 node= s >> 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 >> 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 ~J= uly >>> 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 >>> wrote: >>>> >>>> I've been trying to work out the expected interaction between James >>>> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which b= oth >>>> use variants of BIP91 activation) and the BIP148 UASF [4]. Some of th= is is >>>> subtle so CORRECTIONS WELCOME, but my conclusions are: >>>> 1. It's extremely unlikely BIP91-type logic can activate segwit in tim= e >>>> 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-segwi= t >>>> blocks on midnight (GMT) the morning of August 1. Meanwhile, here are >>>> Bitcoin's rough expected next four difficulty adjustment dates (they c= ould >>>> vary by ~1-3 days depending on block times, but it's unlikely to matte= r >>>> 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 l= ate >>>> to avoid BIP148's split, which will have occurred the moment August be= gan. >>>> So, working backwards, and assuming we want compatibility with old BIP= 141 >>>> 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 activa= te), >>>> by adj #2 (June 30)? >>>> - Therefore, as currently designed, BIP91 bit 4 must be locked in by a= dj >>>> #1 (June 17) >>>> - Therefore, >=3D80% 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 activate= d >>>> 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 s= tat >>>> 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 fe= w >>>> parts of the ecosystem will join the fork, so disruption will be beara= ble. >>>> 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/0145= 08.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 >>