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 E1C108D9 for ; 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 ; Thu, 8 Jun 2017 00:44:40 +0000 (UTC) Received: by mail-ot0-f182.google.com with SMTP id k4so15701388otd.0 for ; 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: References: From: James Hilliard Date: Wed, 7 Jun 2017 19:44:38 -0500 Message-ID: To: Jared Lee Richardson 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > wrote: >> >> On Wed, Jun 7, 2017 at 6:43 PM, Jared Lee Richardson >> 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 >> > >> > wrote: >> >> >> >> On Wed, Jun 7, 2017 at 5:53 PM, Jared Lee Richardson >> >> >> >> 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 >> >> > >> >> > wrote: >> >> >> >> >> >> On Wed, Jun 7, 2017 at 4:50 PM, Jared Lee Richardson >> >> >> >> >> >> 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 >> >> >> > 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 >> >> >> >> 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 >> >> >> >>> 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. >> >> >> >>>> >> >> >> >>>> 
>> >> >> >>>>   BIP: splitprotection
>> >> >> >>>>   Layer: Consensus (soft fork)
>> >> >> >>>>   Title: User Activated Soft Fork Split Protection
>> >> >> >>>>   Author: James Hilliard 
>> >> >> >>>>   Comments-Summary: No comments yet.
>> >> >> >>>>   Comments-URI:
>> >> >> >>>>   Status: Draft
>> >> >> >>>>   Type: Standards Track
>> >> >> >>>>   Created: 2017-05-22
>> >> >> >>>>   License: BSD-3-Clause
>> >> >> >>>>            CC0-1.0
>> >> >> >>>>
>> >> >> >>>> >> >> >> >>>> ==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 === >> >> >> >>>> >> >> >> >>>> 
>> >> >> >>>> // 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");
>> >> >> >>>>     }
>> >> >> >>>> }
>> >> >> >>>>
>> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> 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 >> >> > >> >> > >> > >> > > >