diff options
| author | James Hilliard <james.hilliard1@gmail.com> | 2017-06-07 19:44:38 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-08 00:44:42 +0000 |
| commit | 263770d50f5b901bd0c29381073aab1c8f686ccb (patch) | |
| tree | 6c5a8e4c2a21224da7a445551dfdbc6cc06e75f1 | |
| parent | ba7fbe7e51c08eb301b76db30e056eca154ca714 (diff) | |
| download | pi-bitcoindev-263770d50f5b901bd0c29381073aab1c8f686ccb.tar.gz pi-bitcoindev-263770d50f5b901bd0c29381073aab1c8f686ccb.zip | |
Re: [bitcoin-dev] User Activated Soft Fork Split Protection
| -rw-r--r-- | 6d/d9b8f03b5d5d8cd503a4cdb53cb6c9ade157bf | 831 |
1 files changed, 831 insertions, 0 deletions
diff --git a/6d/d9b8f03b5d5d8cd503a4cdb53cb6c9ade157bf b/6d/d9b8f03b5d5d8cd503a4cdb53cb6c9ade157bf new file mode 100644 index 000000000..9c0f2129a --- /dev/null +++ b/6d/d9b8f03b5d5d8cd503a4cdb53cb6c9ade157bf @@ -0,0 +1,831 @@ +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 +>> >> > +>> >> > +>> > +>> > +> +> + |