path: root/6d/d9b8f03b5d5d8cd503a4cdb53cb6c9ade157bf

Return-Path: <james.hilliard1@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E1C108D9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  8 Jun 2017 00:44:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com
	[74.125.82.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D5D56EB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  8 Jun 2017 00:44:40 +0000 (UTC)
Received: by mail-ot0-f182.google.com with SMTP id k4so15701388otd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 07 Jun 2017 17:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=w13VdNbCxRRG3IkrgT0VUllAlQ10+fxux7Po7acv1Aw=;
	b=Uh0LNvfhiBbUIaGcCEk6LTZmR0eZQeT7CubrY++rIJUHQjevNluAYrP1Yu/OgVSeyW
	AupopFORvlX62a58IfZH5dCFPnusDRV+0ypPkkRgV6+S4yK8Tvxe4MTFJ+k3b+ylwVUC
	1LYOWAoXd8xfa+ok0+NAXskuiceBfe70Lmh+Ot2aPt1JeF1M7EPBpdBTDHRpZXdz8+Hx
	ONUx+nHrUb+qvT9ScmNuH/QEsGmSk8iMU3+bR8QWDZOQ5CHlNt+IEOMUJFkjwAWWXEeW
	fe5C5fhc+nFuLzW152vRg865AgOC8pw5xvy/H/iZuzXYMCCAJid/cdjtSlIhSd11Y6UE
	ryCw==
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;
	bh=w13VdNbCxRRG3IkrgT0VUllAlQ10+fxux7Po7acv1Aw=;
	b=Env/ClAOwBscg+MKFAIAVD1mqHDxEiqStkDDLgM6N+KUC/nZA22Z0CFaGQMuze2Yl4
	bF5BygJ+3Oaf5VbILzsO+WdyZ+QhXQ2SSgURoEyJ5Yt1fSvEbKdgVQRwXgbcFP3b4lJx
	+b9vX5w/klsUdLaCKFswBvGKpttoOfKJFUEXbEBUF3NtFth5dvLxeMwasdB6jQJILCdr
	jd//9U6kmJXaiS3z8h69xTYN2ugewDMLIRzuHq20dgR9nzYpmCaWPvErTyavaxXKNbCR
	/PccrfV3WURUM4okWd98UkdW21McUa+NVUm6X7uBg36aKus6+tNUZPitUs/7jWeEw1/1
	296Q==
X-Gm-Message-State: AKS2vOw+hZirOOStD98Vt9koOhahMrajdrnbabGZVFii/Q9EShUvpsx6
	kjQg6SgHi0a5nAlBLfIgtlaSj/0lAw==
X-Received: by 10.157.7.115 with SMTP id 106mr12021398ote.167.1496882679398;
	Wed, 07 Jun 2017 17:44:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.224.230 with HTTP; Wed, 7 Jun 2017 17:44:38 -0700 (PDT)
In-Reply-To: <CAD1TkXuBc8nQr7ZSog4aYbppqR9Bg4cX=gFdSZCvBXfZmmhQww@mail.gmail.com>
References: <CADvTj4qpH-t5Gx6qyn3yToyUE_GFaBE989=AWNHLKMpMNW3R+w@mail.gmail.com>
	<CAD1TkXviJouao7YoHjiDN3mTUWFEbMY9mtCqkQ8zp8JthyhT7Q@mail.gmail.com>
	<CADvTj4rz4exYMvBEmYi=bTZDgDm0drLjpRZmZUo17inzCzCRVg@mail.gmail.com>
	<CAD1TkXskei1gk_kungSvdWGmbdJMA8AG+-zK+Osz6u5vSCN8BQ@mail.gmail.com>
	<CADvTj4poO1L+Wg5J+M71sJMz-Xcg_st3MkAcQK=bfHhTJ3i8ow@mail.gmail.com>
	<CAD1TkXumetRnPO6LxhJeVoci=0=YHD7hEB0K0YH+2McRBJ-QHw@mail.gmail.com>
	<CADvTj4pFna4tX37XmgrP7ueZB+Yv4T9NWmp99CwKSx5mzdiJJQ@mail.gmail.com>
	<CAD1TkXtmj3H3k+k7X2DgA0cNxXBNSSrzf_o33qFO8cA9eSUTnw@mail.gmail.com>
	<CADvTj4o5tTD2XN080dmHq1DuNwSZtmAytv3=7F5zGeBdhiPMrA@mail.gmail.com>
	<CAD1TkXuBc8nQr7ZSog4aYbppqR9Bg4cX=gFdSZCvBXfZmmhQww@mail.gmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Wed, 7 Jun 2017 19:44:38 -0500
Message-ID: <CADvTj4r6aHYd53Zi-kE+MQZoDv-ONdFf6CDmNA8YXgqVdwmR=g@mail.gmail.com>
To: Jared Lee Richardson <jaredr26@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	LOTS_OF_MONEY,RCVD_IN_DNSWL_NONE autolearn=no 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] User Activated Soft Fork Split Protection
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: Thu, 08 Jun 2017 00:44:43 -0000

On Wed, Jun 7, 2017 at 7:20 PM, Jared Lee Richardson <jaredr26@gmail.com> wrote:
>> Not really, there are a few relatively simple techniques such as RBF
>> which can be leveraged to get confirmations on on-side before double
>> spending on another. Once a transaction is confirmed on the non-BIP148
>> chain then the high fee transactions can be made on only the BIP148
>> side of the split using RBF.
>
> Ah, so the BIP148 client handles this on behalf of its less technical users
> on their behalf then, yes?
It's not automatic but exchanges will likely handle it on behalf of
the less technical users. BIP148 is not intended to cause a permanent
chain split however which is why this was not built in.
>
>>  Exchanges will likely do this splitting
>> automatically for uses as well.
>
> Sure, Exchanges are going to dedicate hundreds of developer hours and
> thousands of support hours to support something that they've repeatedly told
> everyone must have replay protection to be supported.  They're going to do
> this because 8% of nodes and <0.5% of miners say they'll be rewarded richly.
> Somehow I find that hard to believe.
They are very likely to, most have contingency plans for this sort of
thing ready to go due to their experience with the ETH/ETC fork.
>
> Besides, if the BIP148 client does it for them, they wouldn't have to
> dedicate those hundreds of developer hours.  Right?
>
> I can't imagine how this logic is getting you from where the real data is to
> the assumption that an economic majority will push BIP148 into being such a
> more valuable chain that switching chains will be attractive to enough
> miners.  There's got to be some real data that convinces you of this
> somewhere?
If you're looking for hard numbers at this point you aren't likely to
find them because not everything is easy to measure directly.
>
>> Both are issues, but wipeout risk is different, the ETH/ETC split for
>> example didn't have any wipeout risk for either side the same is not
>> true for BIP148(and it is the non-BIP148 side that carries the risk of
>> chain wipeout).
>
> Wipeout risk is a serious issue when 45% of the miners support one chain and
> 55% support the other chain.  Segwit doesn't even have 35% of the miners;
> There's no data or statements anywhere that indicate that UASF is going to
> reach the point where wipeout risk is even comparable to abandonment risk.
It's mostly economic support that will dictate this, not hashpower
support since the hashpower follows the economy.
>
>> Yes, miners aren't likely to waste operational mining costs, that's
>> ultimately why miners would follow the BIP148 side of the chain
>> assuming it has sufficient economic support or if it's more profitable
>> to mine.
>
> To convince miners you would have to have some data SOMEWHERE supporting the
> economic majority argument.  Is there any such data?
We'll know more as we get closer to BIP148 activation by looking at the markets.
>
>> segwit2x has more issues since the HF part requires users to reach
>> consensus
>
> It doesn't have those issues during the segwit activation, ergo there is no
> reason for segwit-activation problems to take priority over the very real
> hardfork activation problems.
And yet segwit2x is insisting on activation bundling which needlessly
complicates and delays SegWit activation.
>
>> That's a political reason not a technical reason.
>
> In a consensus system they are frequently the same, unfortunately.
> Technical awesomeness without people agreeing = zero consensus.  So the
> choice is either to "technically" break the consensus without a
> super-majority and see what happens, or to go with the choice that has real
> data showing the most consensus and hope the tiny minority chain actually
> dies off.
Sure, technical changes can be made for political reasons, we should
at least be clear in regards to why particular decisions are being
made. I'm supportive of a hard fork for technical reasons but not
political ones as are many others.
>
> Jared
>
> On Wed, Jun 7, 2017 at 5:01 PM, James Hilliard <james.hilliard1@gmail.com>
> wrote:
>>
>> On Wed, Jun 7, 2017 at 6:43 PM, Jared Lee Richardson <jaredr26@gmail.com>
>> wrote:
>> >> BIP148 however is a consensus change that can
>> >> be rectified if it gets more work, this would act as an additional
>> >> incentive for mine the BIP148 side since there would be no wipeout
>> >> risk there.
>> >
>> > This statement is misleading.  Wipeout risks don't apply to any
>> > consensus
>> > changes; It is a consensus change, it can only be abandoned.  The BIP148
>> > chain carries just as many risks of being abandoned or even more with
>> > segwit2x on the table.  No miner would consider "wipeout risk" an
>> > advantage
>> > when the real threat is chain abandonment.
>> Both are issues, but wipeout risk is different, the ETH/ETC split for
>> example didn't have any wipeout risk for either side the same is not
>> true for BIP148(and it is the non-BIP148 side that carries the risk of
>> chain wipeout).
>> >
>> >> Higher transaction fees on a minority chain can compensate miners for
>> >> a lower price which would likely be enough to get the BIP148 chain to
>> >> a difficulty reduction.
>> >
>> > Higher transaction fees suffers the same problem as exchange support
>> > does.
>> > Without replay protection, it is very difficult for any average user to
>> > force transactions onto one chain or the other.  Thus, without replay
>> > protection, the UASF chain is unlikely to develop any viable fee market;
>> > Its
>> > few miners 99% of the time will simply choose from the highest fees that
>> > were already available to the other chain, which is basically no
>> > advantage
>> > at all.
>> Not really, there are a few relatively simple techniques such as RBF
>> which can be leveraged to get confirmations on on-side before double
>> spending on another. Once a transaction is confirmed on the non-BIP148
>> chain then the high fee transactions can be made on only the BIP148
>> side of the split using RBF. Exchanges will likely do this splitting
>> automatically for uses as well.
>> >
>> >>  ETC replay protection was done after the fork on an as
>> >> needed basis(there are multiple reliable techniques that can be used
>> >> to split UTXO's), the same can happen with BIP148 and it is easier to
>> >> do with Bitcoin than with the ETH/ETC split IMO.
>> >
>> > ETC replay protection was added because they were already a hardfork and
>> > without it they would not have had a viable chain.  BIP148 is not
>> > supposed
>> > to be a hardfork, and if it added replay protection to remain viable it
>> > would lose the frequently touted "wipeout advantage" as well as the
>> > ability
>> > to call itself a softfork.  And are you seriously suggesting that what
>> > happened with ETC and ETH is a desirable and good situation for Bitcoin,
>> > and
>> > that UASF is ETC?
>> There wasn't proper replay protection at split time for ETH/ETC since
>> normal transactions would get executed on both sides originally,
>> however replay protection was added by wallets(mainly using splitting
>> contracts). I don't think a split is desirable however, which is why
>> I've proposed this BIP.
>> >
>> >> A big reason BIP148 still has support is because up until SegWit
>> >> actually activates there's no guarantee segwit2mb will actually have
>> >> the necessary support to activate SegWit.
>> >
>> > For a miners blowing through six million dollars a day in mining
>> > operational
>> > costs, that's a pretty crappy reason.  Serious miners can't afford to
>> > prop
>> > up a non-viable chain based on philosophy or maybes.  BIP148 is based
>> > entirely upon people who aren't putting anything on the line trying to
>> > convince others to take the huge risks for them.  With deceptively
>> > fallacious logic, in my opinion.
>> Yes, miners aren't likely to waste operational mining costs, that's
>> ultimately why miners would follow the BIP148 side of the chain
>> assuming it has sufficient economic support or if it's more profitable
>> to mine.
>> >
>> > Even segwit2x is based on the assumption that all miners can reach
>> > consensus.  Break that assumption and segwit2x will have the same
>> > problems
>> > as UASF.
>> segwit2x has more issues since the HF part requires users to reach
>> consensus
>> >
>> >> This is largely an issue due to segwit2x's bundling, if the SW and HF
>> >> part of segwit2x were unbundled then there would be no reason to delay
>> >> BIP91 activation
>> >
>> > They are bundled.  Segwit alone doesn't have the desired overwhelming
>> > consensus, unless core wishes to fork 71% to 29%, and maybe not even
>> > that
>> > high.  That's the technical reason, and they can't be unbundled without
>> > breaking that consensus.
>> That's a political reason not a technical reason.
>> >
>> > Jared
>> >
>> >
>> > On Wed, Jun 7, 2017 at 4:11 PM, James Hilliard
>> > <james.hilliard1@gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Jun 7, 2017 at 5:53 PM, Jared Lee Richardson
>> >> <jaredr26@gmail.com>
>> >> wrote:
>> >> >> There are 2 primary factors involved here, economic support and
>> >> > hashpower either of which is enough to make a permanent chain split
>> >> > unlikely, miners will mine whichever chain is most profitable(see
>> >> > ETH/ETC hashpower profitability equilibrium for an example of how
>> >> > this
>> >> > works in practice)
>> >> >
>> >> > That's not a comparable example.  ETC did not face potentially years
>> >> > of
>> >> > slow
>> >> > blocktimes before it normalized, whereas BIP148 is on track to do
>> >> > exactly
>> >> > that.  Moreover, ETC represented a fundamental break from the
>> >> > majority
>> >> > consensus that could not be rectified, whereas BIP148 represents only
>> >> > a
>> >> > minority attempt to accelerate something that an overwhelming
>> >> > majority
>> >> > of
>> >> > miners have already agreed to activate under segwit2x.  Lastly ETC
>> >> > was
>> >> > required to add replay protection, just like any minority fork
>> >> > proposed
>> >> > by
>> >> > any crypto-currency has been, something that BIP148 both lacks and
>> >> > refuses
>> >> > to add or even acknowledge the necessity of.  Without replay
>> >> > protection,
>> >> > ETC
>> >> > could not have become profitable enough to be a viable minority
>> >> > chain.
>> >> > If
>> >> > BIP148's chain is not the majority chain and it does not have replay
>> >> > protection, it will face the same problems, but that required replay
>> >> > protection will turn it into a hardfork.  This will be a very bad
>> >> > position
>> >> > for UASF supporters to find themselves in - Either hardfork and hope
>> >> > the
>> >> > price is higher and the majority converts, or die as the minority
>> >> > chain
>> >> > with
>> >> > no reliable methods of economic conversion.
>> >> Higher transaction fees on a minority chain can compensate miners for
>> >> a lower price which would likely be enough to get the BIP148 chain to
>> >> a difficulty reduction. BIP148 however is a consensus change that can
>> >> be rectified if it gets more work, this would act as an additional
>> >> incentive for mine the BIP148 side since there would be no wipeout
>> >> risk there. ETC replay protection was done after the fork on an as
>> >> needed basis(there are multiple reliable techniques that can be used
>> >> to split UTXO's), the same can happen with BIP148 and it is easier to
>> >> do with Bitcoin than with the ETH/ETC split IMO.
>> >> >
>> >> > I believe, but don't have data to back this, that most of the BIP148
>> >> > insistence comes not from a legitimate attempt to gain consensus (or
>> >> > else
>> >> > they would either outright oppose segwit2mb for its hardfork, or they
>> >> > would
>> >> > outright support it), but rather from an attempt for BIP148
>> >> > supporters
>> >> > to
>> >> > save face for BIP148 being a failure.  If I'm correct, that's a
>> >> > terrible
>> >> > and
>> >> > highly non-technical reason for segwit2mb to bend over backwards
>> >> > attempting
>> >> > to support BIP148's attempt to save face.
>> >> A big reason BIP148 still has support is because up until SegWit
>> >> actually activates there's no guarantee segwit2mb will actually have
>> >> the necessary support to activate SegWit.
>> >> >
>> >> >> The main issue is just one of activation timelines, BIP91 as
>> >> > is takes too long to activate unless started ahead of the existing
>> >> > segwit2x schedule and it's unlikely that BIP148 will get pushed back
>> >> > any further.
>> >> >
>> >> > Even if I'm not correct on the above, I and others find it hard to
>> >> > accept
>> >> > that this timeline conflict is segwit2x's fault.  Segwit2x has both
>> >> > some
>> >> > flexibility and broad support that crosses contentious pro-segwit and
>> >> > pro-blocksize-increase divisions that have existed for two years.
>> >> > BIP148 is
>> >> > attempting to hold segwit2x's timelines and code hostage by claiming
>> >> > inflexibility and claiming broad support, and not only are neither of
>> >> > those
>> >> > assertions are backed by real data, BIP148 (by being so inflexible)
>> >> > is
>> >> > pushing a position that deepens the divides between those groups.
>> >> > For
>> >> > there
>> >> > to be technical reasons for compatibility (so long as there are
>> >> > tradeoffs,
>> >> > which there are), there needs to be hard data showing that BIP148 is
>> >> > a
>> >> > viable minority fork that won't simply die off on its own.
>> >> This is largely an issue due to segwit2x's bundling, if the SW and HF
>> >> part of segwit2x were unbundled then there would be no reason to delay
>> >> BIP91 activation, this is especially a problem since it takes a good
>> >> deal of time to properly code and test a HF. Unfortunately segwit2x
>> >> has been quite inflexible in regards to the bundling aspect even
>> >> though there are clearly no technical reasons for it to be there.
>> >> >
>> >> > Jared
>> >> >
>> >> >
>> >> > On Wed, Jun 7, 2017 at 3:23 PM, James Hilliard
>> >> > <james.hilliard1@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Wed, Jun 7, 2017 at 4:50 PM, Jared Lee Richardson
>> >> >> <jaredr26@gmail.com>
>> >> >> wrote:
>> >> >> > Could this risk mitigation measure be an optional flag?  And if
>> >> >> > so,
>> >> >> > could it+BIP91 signal on a different bit than bit4?
>> >> >> It's fairly trivial for miners to signal for BIP91 on bit4 or a
>> >> >> different bit at the same time as the code is trivial enough to
>> >> >> combine
>> >> >> >
>> >> >> > The reason being, if for some reason the segwit2x activation
>> >> >> > cannot
>> >> >> > take place in time, it would be preferable for miners to have a
>> >> >> > more
>> >> >> > standard approach to activation that requires stronger consensus
>> >> >> > and
>> >> >> > may be more forgiving than BIP148.  If the segwit2x activation is
>> >> >> > on
>> >> >> > time to cooperate with BIP148, it could be signaled through the
>> >> >> > non-bit4 approach and everything could go smoothly.  Thoughts on
>> >> >> > that
>> >> >> > idea?  It may add more complexity and more developer time, but may
>> >> >> > also address your concerns among others.
>> >> >> This does give miners another approach to activate segwit ahead of
>> >> >> BIP148, if segwit2x activation is rolled out and activated
>> >> >> immediately
>> >> >> then this would not be needed however based on the timeline here
>> >> >> https://segwit2x.github.io/ it would not be possible for BIP91 to
>> >> >> enforce mandatory signalling ahead of BIP148. Maybe that can be
>> >> >> changed though, I've suggested an immediate rollout with a
>> >> >> placeholder
>> >> >> client timeout instead of the HF code initially in order to
>> >> >> accelerate
>> >> >> that.
>> >> >> >
>> >> >> >> Since this BIP
>> >> >> >> only activates with a clear miner majority it should not increase
>> >> >> >> the
>> >> >> >> risk of an extended chain split.
>> >> >> >
>> >> >> > The concern I'm raising is more about the psychology of giving
>> >> >> > BIP148
>> >> >> > a sense of safety that may not be valid.  Without several more
>> >> >> > steps,
>> >> >> > BIP148 is definitely on track to be a risky chainsplit, and
>> >> >> > without
>> >> >> > segwit2x it will almost certainly be a small minority chain.
>> >> >> > (Unless
>> >> >> > the segwit2x compromise falls apart before then, and even in that
>> >> >> > case
>> >> >> > it is likely to be a minority chain)
>> >> >> There are 2 primary factors involved here, economic support and
>> >> >> hashpower either of which is enough to make a permanent chain split
>> >> >> unlikely, miners will mine whichever chain is most profitable(see
>> >> >> ETH/ETC hashpower profitability equilibrium for an example of how
>> >> >> this
>> >> >> works in practice) however there may be lag time immediately after
>> >> >> the
>> >> >> split if there is an economic majority but not a hashpower majority
>> >> >> initially. This is risk mitigation that only requires miners support
>> >> >> however. The main issue is just one of activation timelines, BIP91
>> >> >> as
>> >> >> is takes too long to activate unless started ahead of the existing
>> >> >> segwit2x schedule and it's unlikely that BIP148 will get pushed back
>> >> >> any further.
>> >> >> >
>> >> >> > Jared
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Jun 7, 2017 at 2:42 PM, James Hilliard
>> >> >> > <james.hilliard1@gmail.com> wrote:
>> >> >> >> I don't really see how this would increase the likelihood of an
>> >> >> >> extended chain split assuming BIP148 is going to have
>> >> >> >> non-insignificant economic backing. This BIP is designed to
>> >> >> >> provide
>> >> >> >> a
>> >> >> >> risk mitigation measure that miners can safely deploy. Since this
>> >> >> >> BIP
>> >> >> >> only activates with a clear miner majority it should not increase
>> >> >> >> the
>> >> >> >> risk of an extended chain split. At this point it is not
>> >> >> >> completely
>> >> >> >> clear how much economic support there is for BIP148 but support
>> >> >> >> certainly seems to be growing and we have nearly 2 months until
>> >> >> >> BIP148
>> >> >> >> activation. I intentionally used a shorter activation period here
>> >> >> >> so
>> >> >> >> that decisions by miners can be made close to the BIP148
>> >> >> >> activation
>> >> >> >> date.
>> >> >> >>
>> >> >> >> On Wed, Jun 7, 2017 at 4:29 PM, Jared Lee Richardson
>> >> >> >> <jaredr26@gmail.com> wrote:
>> >> >> >>> I think this BIP represents a gamble, and the gamble may not be
>> >> >> >>> a
>> >> >> >>> good
>> >> >> >>> one.  The gamble here is that if the segwit2x changes are rolled
>> >> >> >>> out
>> >> >> >>> on time, and if the signatories accept the bit4 + bit1 signaling
>> >> >> >>> proposals within BIP91, the launch will go smoother, as
>> >> >> >>> intended.
>> >> >> >>> But
>> >> >> >>> conversely, if either the segwit2x signatories balk about the
>> >> >> >>> Bit1
>> >> >> >>> signaling OR if the timelines for segwit2mb are missed even by a
>> >> >> >>> bit,
>> >> >> >>> it may cause the BIP148 chainsplit to be worse than it would be
>> >> >> >>> without.  Given the frequent concerns raised in multiple places
>> >> >> >>> about
>> >> >> >>> the aggressiveness of the segwit2x timelines, including the
>> >> >> >>> non-hardfork timelines, this does not seem like a great gamble
>> >> >> >>> to
>> >> >> >>> be
>> >> >> >>> making.
>> >> >> >>>
>> >> >> >>> The reason I say it may make the chainsplit be worse than it
>> >> >> >>> would
>> >> >> >>> otherwise be is that it may provide a false sense of safety for
>> >> >> >>> BIP148
>> >> >> >>> that currently does not currently exist(and should not, as it is
>> >> >> >>> a
>> >> >> >>> chainsplit).  That sense of safety would only be legitimate if
>> >> >> >>> the
>> >> >> >>> segwit2x signatories were on board, and the segwit2x code
>> >> >> >>> effectively
>> >> >> >>> enforced BIP148 simultaneously, neither of which are guaranteed.
>> >> >> >>> If
>> >> >> >>> users and more miners had a false sense that BIP148 was *not*
>> >> >> >>> going
>> >> >> >>> to
>> >> >> >>> chainsplit from default / segwit2x, they might not follow the
>> >> >> >>> news
>> >> >> >>> if
>> >> >> >>> suddenly the segwit2x plan were delayed for a few days.  While
>> >> >> >>> any
>> >> >> >>> additional support would definitely be cheered on by BIP148
>> >> >> >>> supporters, the practical reality might be that this proposal
>> >> >> >>> would
>> >> >> >>> take BIP148 from the "unlikely to have any viable chain after
>> >> >> >>> flag
>> >> >> >>> day
>> >> >> >>> without segwit2x" category into the "small but viable minority
>> >> >> >>> chain"
>> >> >> >>> category, and even worse, it might strengthen the chainsplit
>> >> >> >>> just
>> >> >> >>> days
>> >> >> >>> before segwit is activated on BOTH chains, putting the BIP148
>> >> >> >>> supporters on the wrong pro-segwit, but still-viable chain.
>> >> >> >>>
>> >> >> >>> If Core had taken a strong stance to include BIP148 into the
>> >> >> >>> client,
>> >> >> >>> and if BIP148 support were much much broader, I would feel
>> >> >> >>> differently
>> >> >> >>> as the gamble would be more likely to discourage a chainsplit
>> >> >> >>> (By
>> >> >> >>> forcing the acceleration of segwit2x) rather than encourage it
>> >> >> >>> (by
>> >> >> >>> strengthening an extreme minority chainsplit that may wind up on
>> >> >> >>> the
>> >> >> >>> wrong side of two segwit-activated chains).  As it stands now,
>> >> >> >>> this
>> >> >> >>> seems like a very dangerous attempt to compromise with a small
>> >> >> >>> but
>> >> >> >>> vocal group that are the ones creating the threat to begin with.
>> >> >> >>>
>> >> >> >>> Jared
>> >> >> >>>
>> >> >> >>> On Tue, Jun 6, 2017 at 5:56 PM, James Hilliard via bitcoin-dev
>> >> >> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >> >> >>>> Due to the proposed calendar(https://segwit2x.github.io/) for
>> >> >> >>>> the
>> >> >> >>>> SegWit2x agreement being too slow to activate SegWit mandatory
>> >> >> >>>> signalling ahead of BIP148 using BIP91 I would like to propose
>> >> >> >>>> another
>> >> >> >>>> option that miners can use to prevent a chain split ahead of
>> >> >> >>>> the
>> >> >> >>>> Aug
>> >> >> >>>> 1st BIP148 activation date.
>> >> >> >>>>
>> >> >> >>>> The splitprotection soft fork is essentially BIP91 but using
>> >> >> >>>> BIP8
>> >> >> >>>> instead of BIP9 with a lower activation threshold and immediate
>> >> >> >>>> mandatory signalling lock-in. This allows for a majority of
>> >> >> >>>> miners
>> >> >> >>>> to
>> >> >> >>>> activate mandatory SegWit signalling and prevent a potential
>> >> >> >>>> chain
>> >> >> >>>> split ahead of BIP148 activation.
>> >> >> >>>>
>> >> >> >>>> This BIP allows for miners to respond to market forces quickly
>> >> >> >>>> ahead
>> >> >> >>>> of BIP148 activation by signalling for splitprotection. Any
>> >> >> >>>> miners
>> >> >> >>>> already running BIP148 should be encouraged to use
>> >> >> >>>> splitprotection.
>> >> >> >>>>
>> >> >> >>>> <pre>
>> >> >> >>>>   BIP: splitprotection
>> >> >> >>>>   Layer: Consensus (soft fork)
>> >> >> >>>>   Title: User Activated Soft Fork Split Protection
>> >> >> >>>>   Author: James Hilliard <james.hilliard1@gmail.com>
>> >> >> >>>>   Comments-Summary: No comments yet.
>> >> >> >>>>   Comments-URI:
>> >> >> >>>>   Status: Draft
>> >> >> >>>>   Type: Standards Track
>> >> >> >>>>   Created: 2017-05-22
>> >> >> >>>>   License: BSD-3-Clause
>> >> >> >>>>            CC0-1.0
>> >> >> >>>> </pre>
>> >> >> >>>>
>> >> >> >>>> ==Abstract==
>> >> >> >>>>
>> >> >> >>>> This document specifies a coordination mechanism for a simple
>> >> >> >>>> majority
>> >> >> >>>> of miners to prevent a chain split ahead of BIP148 activation.
>> >> >> >>>>
>> >> >> >>>> ==Definitions==
>> >> >> >>>>
>> >> >> >>>> "existing segwit deployment" refer to the BIP9 "segwit"
>> >> >> >>>> deployment
>> >> >> >>>> using bit 1, between November 15th 2016 and November 15th 2017
>> >> >> >>>> to
>> >> >> >>>> activate BIP141, BIP143 and BIP147.
>> >> >> >>>>
>> >> >> >>>> ==Motivation==
>> >> >> >>>>
>> >> >> >>>> The biggest risk of BIP148 is an extended chain split, this BIP
>> >> >> >>>> provides a way for a simple majority of miners to eliminate
>> >> >> >>>> that
>> >> >> >>>> risk.
>> >> >> >>>>
>> >> >> >>>> This BIP provides a way for a simple majority of miners to
>> >> >> >>>> coordinate
>> >> >> >>>> activation of the existing segwit deployment with less than 95%
>> >> >> >>>> hashpower before BIP148 activation. Due to time constraints
>> >> >> >>>> unless
>> >> >> >>>> immediately deployed BIP91 will likely not be able to enforce
>> >> >> >>>> mandatory signalling of segwit before the Aug 1st activation of
>> >> >> >>>> BIP148. This BIP provides a method for rapid miner activation
>> >> >> >>>> of
>> >> >> >>>> SegWit mandatory signalling ahead of the BIP148 activation
>> >> >> >>>> date.
>> >> >> >>>> Since
>> >> >> >>>> the primary goal of this BIP is to reduce the chance of an
>> >> >> >>>> extended
>> >> >> >>>> chain split as much as possible we activate using a simple
>> >> >> >>>> miner
>> >> >> >>>> majority of 65% over a 504 block interval rather than a higher
>> >> >> >>>> percentage. This BIP also allows miners to signal their
>> >> >> >>>> intention
>> >> >> >>>> to
>> >> >> >>>> run BIP148 in order to prevent a chain split.
>> >> >> >>>>
>> >> >> >>>> ==Specification==
>> >> >> >>>>
>> >> >> >>>> While this BIP is active, all blocks must set the nVersion
>> >> >> >>>> header
>> >> >> >>>> top
>> >> >> >>>> 3 bits to 001 together with bit field (1<<1) (according to the
>> >> >> >>>> existing segwit deployment). Blocks that do not signal as
>> >> >> >>>> required
>> >> >> >>>> will be rejected.
>> >> >> >>>>
>> >> >> >>>> ==Deployment==
>> >> >> >>>>
>> >> >> >>>> This BIP will be deployed by "version bits" with a 65%(this can
>> >> >> >>>> be
>> >> >> >>>> adjusted if desired) activation threshold BIP9 with the name
>> >> >> >>>> "splitprotecion" and using bit 2.
>> >> >> >>>>
>> >> >> >>>> This BIP starts immediately and is a BIP8 style soft fork since
>> >> >> >>>> mandatory signalling will start on midnight August 1st 2017
>> >> >> >>>> (epoch
>> >> >> >>>> time 1501545600) regardless of whether or not this BIP has
>> >> >> >>>> reached
>> >> >> >>>> its
>> >> >> >>>> own signalling threshold. This BIP will cease to be active when
>> >> >> >>>> segwit
>> >> >> >>>> is locked-in.
>> >> >> >>>>
>> >> >> >>>> === Reference implementation ===
>> >> >> >>>>
>> >> >> >>>> <pre>
>> >> >> >>>> // Check if Segregated Witness is Locked In
>> >> >> >>>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> >> >> >>>> Consensus::Params& params)
>> >> >> >>>> {
>> >> >> >>>>     LOCK(cs_main);
>> >> >> >>>>     return (VersionBitsState(pindexPrev, params,
>> >> >> >>>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>> >> >> >>>> THRESHOLD_LOCKED_IN);
>> >> >> >>>> }
>> >> >> >>>>
>> >> >> >>>> // SPLITPROTECTION mandatory segwit signalling.
>> >> >> >>>> if ( VersionBitsState(pindex->pprev,
>> >> >> >>>> chainparams.GetConsensus(),
>> >> >> >>>> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
>> >> >> >>>> THRESHOLD_LOCKED_IN &&
>> >> >> >>>>      !IsWitnessLockedIn(pindex->pprev,
>> >> >> >>>> chainparams.GetConsensus())
>> >> >> >>>> &&
>> >> >> >>>> // Segwit is not locked in
>> >> >> >>>>      !IsWitnessEnabled(pindex->pprev,
>> >> >> >>>> chainparams.GetConsensus())
>> >> >> >>>> )
>> >> >> >>>> //
>> >> >> >>>> and is not active.
>> >> >> >>>> {
>> >> >> >>>>     bool fVersionBits = (pindex->nVersion &
>> >> >> >>>> VERSIONBITS_TOP_MASK)
>> >> >> >>>> ==
>> >> >> >>>> VERSIONBITS_TOP_BITS;
>> >> >> >>>>     bool fSegbit = (pindex->nVersion &
>> >> >> >>>> VersionBitsMask(chainparams.GetConsensus(),
>> >> >> >>>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> >> >> >>>>     if (!(fVersionBits && fSegbit)) {
>> >> >> >>>>         return state.DoS(0, error("ConnectBlock(): relayed
>> >> >> >>>> block
>> >> >> >>>> must
>> >> >> >>>> signal for segwit, please upgrade"), REJECT_INVALID,
>> >> >> >>>> "bad-no-segwit");
>> >> >> >>>>     }
>> >> >> >>>> }
>> >> >> >>>>
>> >> >> >>>> // BIP148 mandatory segwit signalling.
>> >> >> >>>> int64_t nMedianTimePast = pindex->GetMedianTimePast();
>> >> >> >>>> if ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017
>> >> >> >>>> 00:00:00
>> >> >> >>>> UTC
>> >> >> >>>>      (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017
>> >> >> >>>> 00:00:00
>> >> >> >>>> UTC
>> >> >> >>>>      (!IsWitnessLockedIn(pindex->pprev,
>> >> >> >>>> chainparams.GetConsensus())
>> >> >> >>>> &&
>> >> >> >>>>  // Segwit is not locked in
>> >> >> >>>>       !IsWitnessEnabled(pindex->pprev,
>> >> >> >>>> chainparams.GetConsensus())) )
>> >> >> >>>>  // and is not active.
>> >> >> >>>> {
>> >> >> >>>>     bool fVersionBits = (pindex->nVersion &
>> >> >> >>>> VERSIONBITS_TOP_MASK)
>> >> >> >>>> ==
>> >> >> >>>> VERSIONBITS_TOP_BITS;
>> >> >> >>>>     bool fSegbit = (pindex->nVersion &
>> >> >> >>>> VersionBitsMask(chainparams.GetConsensus(),
>> >> >> >>>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> >> >> >>>>     if (!(fVersionBits && fSegbit)) {
>> >> >> >>>>         return state.DoS(0, error("ConnectBlock(): relayed
>> >> >> >>>> block
>> >> >> >>>> must
>> >> >> >>>> signal for segwit, please upgrade"), REJECT_INVALID,
>> >> >> >>>> "bad-no-segwit");
>> >> >> >>>>     }
>> >> >> >>>> }
>> >> >> >>>> </pre>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-v0.14.1
>> >> >> >>>>
>> >> >> >>>> ==Backwards Compatibility==
>> >> >> >>>>
>> >> >> >>>> This deployment is compatible with the existing "segwit" bit 1
>> >> >> >>>> deployment scheduled between midnight November 15th, 2016 and
>> >> >> >>>> midnight
>> >> >> >>>> November 15th, 2017. This deployment is also compatible with
>> >> >> >>>> the
>> >> >> >>>> existing BIP148 deployment. This BIP is compatible with BIP91
>> >> >> >>>> only
>> >> >> >>>> if
>> >> >> >>>> BIP91 activates before it and before BIP148. Miners will need
>> >> >> >>>> to
>> >> >> >>>> upgrade their nodes to support splitprotection otherwise they
>> >> >> >>>> may
>> >> >> >>>> build on top of an invalid block. While this bip is active
>> >> >> >>>> users
>> >> >> >>>> should either upgrade to splitprotection or wait for additional
>> >> >> >>>> confirmations when accepting payments.
>> >> >> >>>>
>> >> >> >>>> ==Rationale==
>> >> >> >>>>
>> >> >> >>>> Historically we have used IsSuperMajority() to activate soft
>> >> >> >>>> forks
>> >> >> >>>> such as BIP66 which has a mandatory signalling requirement for
>> >> >> >>>> miners
>> >> >> >>>> once activated, this ensures that miners are aware of new rules
>> >> >> >>>> being
>> >> >> >>>> enforced. This technique can be leveraged to lower the
>> >> >> >>>> signalling
>> >> >> >>>> threshold of a soft fork while it is in the process of being
>> >> >> >>>> deployed
>> >> >> >>>> in a backwards compatible way. We also use a BIP8 style timeout
>> >> >> >>>> to
>> >> >> >>>> ensure that this BIP is compatible with BIP148 and that BIP148
>> >> >> >>>> compatible mandatory signalling activates regardless of miner
>> >> >> >>>> signalling levels.
>> >> >> >>>>
>> >> >> >>>> By orphaning non-signalling blocks during the BIP9 bit 1
>> >> >> >>>> "segwit"
>> >> >> >>>> deployment, this BIP can cause the existing "segwit" deployment
>> >> >> >>>> to
>> >> >> >>>> activate without needing to release a new deployment. As we
>> >> >> >>>> approach
>> >> >> >>>> BIP148 activation it may be desirable for a majority of miners
>> >> >> >>>> to
>> >> >> >>>> have
>> >> >> >>>> a method that will ensure that there is no chain split.
>> >> >> >>>>
>> >> >> >>>> ==References==
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
>> >> >> >>>> Mailing list discussion]
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
>> >> >> >>>> P2SH flag day activation]
>> >> >> >>>> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and
>> >> >> >>>> delay]]
>> >> >> >>>> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
>> >> >> >>>> *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
>> >> >> >>>> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus
>> >> >> >>>> layer)]]
>> >> >> >>>> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification
>> >> >> >>>> for
>> >> >> >>>> Version 0 Witness Program]]
>> >> >> >>>> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element
>> >> >> >>>> malleability]]
>> >> >> >>>> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit
>> >> >> >>>> deployment]]
>> >> >> >>>> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second
>> >> >> >>>> deployment)]]
>> >> >> >>>> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit
>> >> >> >>>> benefits]
>> >> >> >>>>
>> >> >> >>>> ==Copyright==
>> >> >> >>>>
>> >> >> >>>> This document is dual licensed as BSD 3-clause, and Creative
>> >> >> >>>> Commons
>> >> >> >>>> CC0 1.0 Universal.
>> >> >> >>>> _______________________________________________
>> >> >> >>>> bitcoin-dev mailing list
>> >> >> >>>> bitcoin-dev@lists.linuxfoundation.org
>> >> >> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >
>> >> >
>> >
>> >
>
>