path: root/c8/aeadf078ed8e00219a3a729b7575435cfb1460

Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E5055723
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Jun 2017 17:12:36 +0000 (UTC)
Received: by mail-vk0-f54.google.com with SMTP id g66so41323643vki.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CABm2gDp8Dvi1eLOOU9E04OvVZR5U1=6bn9vf9k8=di66eg2EQA@mail.gmail.com>
References: <CAAUaCygRaXNX5xWuka1xrrXwKv1tqevT9-cHd-5mh_AkHpg9gA@mail.gmail.com>
	<CAAUaCyh_uBcZ7ntbLtOeOAK-6nt2Rx-cxx27QaiXRKkije21AQ@mail.gmail.com>
	<CAAUaCyiwnspvJ9HY41GK8tMsA4ezpFPR1Ka9upik6UwsYBASnQ@mail.gmail.com>
	<CABm2gDp8Dvi1eLOOU9E04OvVZR5U1=6bn9vf9k8=di66eg2EQA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sun, 11 Jun 2017 19:12:35 +0200
Message-ID: <CABm2gDpy8XA3Nh+amYMb4GamOy+FdjwSGc19X6HtNJg2YkNH0w@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jtimon@jtimon.cc> wrote:
> On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
> <bitcoin-dev@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 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 <jacob.eliosoff@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 ~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 <jacob.eliosoff@gmail.c=
om>
>>> 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
>>