diff options
| author | Jared Lee Richardson <jaredr26@gmail.com> | 2017-06-07 15:53:14 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-07 22:53:18 +0000 |
| commit | 96765d9ca9bcad2d307efc0eeaade36e31f2f67a (patch) | |
| tree | 276b18a7a76c3b9759922555f2f00ff14cb36462 | |
| parent | b671182657af49b4efdffbb7eaae79638615472c (diff) | |
| download | pi-bitcoindev-96765d9ca9bcad2d307efc0eeaade36e31f2f67a.tar.gz pi-bitcoindev-96765d9ca9bcad2d307efc0eeaade36e31f2f67a.zip | |
Re: [bitcoin-dev] User Activated Soft Fork Split Protection
| -rw-r--r-- | aa/d36ec3ba17ce37b704b2182ecedf823a10b34d | 968 |
1 files changed, 968 insertions, 0 deletions
diff --git a/aa/d36ec3ba17ce37b704b2182ecedf823a10b34d b/aa/d36ec3ba17ce37b704b2182ecedf823a10b34d new file mode 100644 index 000000000..1f7da9f75 --- /dev/null +++ b/aa/d36ec3ba17ce37b704b2182ecedf823a10b34d @@ -0,0 +1,968 @@ +Return-Path: <jaredr26@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id AC791B37 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Jun 2017 22:53:18 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com + [209.85.213.53]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FEF71F3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Jun 2017 22:53:16 +0000 (UTC) +Received: by mail-vk0-f53.google.com with SMTP id g66so10869599vki.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 07 Jun 2017 15:53:16 -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=MQ6AnUtFtehCSbws475IxZWwi2WVajW+G8E0WqoghW8=; + b=fcrm3GuFa7soO6CRzf0Hz3PUEtU2w9VuxuQsRflw9DZPymL5DaGyelKLWpKSy9X/AI + XlLawMQ0JfD9m6djvWHrKXy+V3A+F5GspCKCa5ukna01BHmCvQydvG5GIDQRJvFbyewM + EXvIVpZ25Q5eCIAc5YkOHLILHJcI4r2OA7LOJWzVCJtmspwmWkU53QBI638ZyMXt67pt + GRHW93NqYYKQaO9xw3T7ncYFxzkpAWyhHTDoi1iOvf2AU4+4A3T9E9tG+L3kVEsop7y4 + WJnv4IEPdWzfSuox3Iv8HPDB4d/9mYwY2HXYFoxBTi4ZeWb8AxrJ7EINNTCv7PQlwEhx + GRrQ== +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=MQ6AnUtFtehCSbws475IxZWwi2WVajW+G8E0WqoghW8=; + b=kVGy71Y06YlSfUm95RRhQwEjx/ZMTxDFDF/AFVL1rAZP2KID7ZelXe0nhZye3epnX7 + nlipD2YoG3CbchAUmCEko+qXdD5avPcS7l82xI4nqWOaezPIDLF4l7jh/0BsOj8E+rA3 + BxvsBaSXErUsvhfiq+mnsPEEML/6aF7pfmwP26rW6UzFJ7hC8OszdCkkA6+HO5RLg4IV + ig/BJmEnic0gtqGjLqxH1935Rv4skrtMAxKjGwWfk1tx1EflW6JIXrTEb5Rj+iYwUDwG + ySAs8CD28FIhRjZQe9w2TrtDZ/3QJIJvKUGZybE3R+t0avPLMLhVdJwrXdW8GAu58OZw + pcLg== +X-Gm-Message-State: AODbwcA5CQGwbedg5VzzL2VpvVvFOCYdfG1T3bnNCk54z3iQa+Ze1pZr + pfebD1sMZEi0Y3L5fy+wXl85VCKZFw== +X-Received: by 10.31.137.145 with SMTP id l139mr17821576vkd.39.1496875995266; + Wed, 07 Jun 2017 15:53:15 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.31.157.215 with HTTP; Wed, 7 Jun 2017 15:53:14 -0700 (PDT) +In-Reply-To: <CADvTj4poO1L+Wg5J+M71sJMz-Xcg_st3MkAcQK=bfHhTJ3i8ow@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> +From: Jared Lee Richardson <jaredr26@gmail.com> +Date: Wed, 7 Jun 2017 15:53:14 -0700 +Message-ID: <CAD1TkXumetRnPO6LxhJeVoci=0=YHD7hEB0K0YH+2McRBJ-QHw@mail.gmail.com> +To: James Hilliard <james.hilliard1@gmail.com> +Content-Type: multipart/alternative; boundary="001a11457cc2f8847c055166995d" +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, + HTML_MESSAGE,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 +X-Mailman-Approved-At: Wed, 07 Jun 2017 22:59:58 +0000 +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: Wed, 07 Jun 2017 22:53:18 -0000 + +--001a11457cc2f8847c055166995d +Content-Type: text/plain; charset="UTF-8" + +> 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. + +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. + +> 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. + +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 +> + +--001a11457cc2f8847c055166995d +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">There are 2 pri= +mary factors involved here, economic support and</span><br style=3D"font-si= +ze:12.8px"><span style=3D"font-size:12.8px">hashpower either of which is en= +ough to make a permanent chain split</span><br style=3D"font-size:12.8px"><= +span style=3D"font-size:12.8px">unlikely, miners will mine whichever chain = +is most profitable(see</span><br style=3D"font-size:12.8px"><span style=3D"= +font-size:12.8px">ETH/ETC hashpower profitability equilibrium for an exampl= +e of how this</span><br style=3D"font-size:12.8px"><span style=3D"font-size= +:12.8px">works in practice)=C2=A0</span><br><br><span style=3D"font-size:12= +.8px">That's not a comparable example.=C2=A0 ETC did not face potential= +ly years of slow blocktimes before it normalized, whereas BIP148 is on trac= +k to do exactly that.=C2=A0 Moreover, ETC represented a fundamental break f= +rom the majority consensus that could not be rectified, whereas BIP148 repr= +esents only a minority attempt to accelerate something that an overwhelming= + majority of miners have already agreed to activate under segwit2x.=C2=A0 L= +astly ETC was required to add replay protection</span><span style=3D"font-s= +ize:12.8px">, just like any minority fork proposed by any crypto-currency h= +as been, something that BIP148 both lacks and refuses to add or even acknow= +ledge the necessity of.=C2=A0 Without replay protection, ETC could not have= + become profitable enough to be a viable minority chain.=C2=A0 If BIP148= +9;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 t= +urn it into a hardfork.=C2=A0 This will be a very bad position for UASF sup= +porters to find themselves in - Either hardfork and hope the price is highe= +r and the majority converts, or die as the minority chain with no reliable = +methods of economic conversion.</span><span style=3D"font-size:12.8px"><br>= +<br>I believe, but don't have data to back this, that most of the BIP14= +8 insistence comes not from a legitimate attempt to gain consensus=C2=A0(or= + else they would either outright oppose segwit2mb for its hardfork, or they= + would outright support it), but rather from an attempt for BIP148 supporte= +rs to save face for BIP148 being a failure.=C2=A0 If I'm correct, that&= +#39;s a terrible and highly non-technical reason for segwit2mb to bend over= + backwards attempting to support BIP148's attempt to save face.</span><= +br><br>>=C2=A0<span style=3D"font-size:12.8px">The main issue is just on= +e of activation timelines, BIP91 as</span><br style=3D"font-size:12.8px"><s= +pan style=3D"font-size:12.8px">is takes too long to activate unless started= + ahead of the existing</span><br style=3D"font-size:12.8px"><span style=3D"= +font-size:12.8px">segwit2x schedule and it's unlikely that BIP148 will = +get pushed back</span><br style=3D"font-size:12.8px"><span style=3D"font-si= +ze:12.8px">any further.</span><br><br>Even if I'm not correct on the ab= +ove, I and others find it hard to accept that this timeline conflict is seg= +wit2x's fault.=C2=A0 Segwit2x has both some flexibility and broad suppo= +rt that crosses contentious pro-segwit and pro-blocksize-increase divisions= + that have existed for two years.=C2=A0 BIP148 is attempting to hold segwit= +2x's timelines and code hostage by claiming inflexibility and claiming = +broad support, and not only are neither of those assertions are backed by r= +eal data, BIP148 (by being so inflexible) is pushing a position that deepen= +s the divides between those groups.=C2=A0 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 w= +on't simply die off on its own.<br><br>Jared<br><br></div><div class=3D= +"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 7, 2017 at 3:23 PM= +, James Hilliard <span dir=3D"ltr"><<a href=3D"mailto:james.hilliard1@gm= +ail.com" target=3D"_blank">james.hilliard1@gmail.com</a>></span> wrote:<= +br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= +:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Jun 7, 2017 at 4= +:50 PM, Jared Lee Richardson <<a href=3D"mailto:jaredr26@gmail.com">jare= +dr26@gmail.com</a>> wrote:<br> +> Could this risk mitigation measure be an optional flag?=C2=A0 And if s= +o,<br> +> could it+BIP91 signal on a different bit than bit4?<br> +</span>It's fairly trivial for miners to signal for BIP91 on bit4 or a<= +br> +different bit at the same time as the code is trivial enough to<br> +combine<br> +<span class=3D"">><br> +> The reason being, if for some reason the segwit2x activation cannot<br= +> +> take place in time, it would be preferable for miners to have a more<b= +r> +> standard approach to activation that requires stronger consensus and<b= +r> +> may be more forgiving than BIP148.=C2=A0 If the segwit2x activation is= + on<br> +> time to cooperate with BIP148, it could be signaled through the<br> +> non-bit4 approach and everything could go smoothly.=C2=A0 Thoughts on = +that<br> +> idea?=C2=A0 It may add more complexity and more developer time, but ma= +y<br> +> also address your concerns among others.<br> +</span>This does give miners another approach to activate segwit ahead of<b= +r> +BIP148, if segwit2x activation is rolled out and activated immediately<br> +then this would not be needed however based on the timeline here<br> +<a href=3D"https://segwit2x.github.io/" rel=3D"noreferrer" target=3D"_blank= +">https://segwit2x.github.io/</a> it would not be possible for BIP91 to<br> +enforce mandatory signalling ahead of BIP148. Maybe that can be<br> +changed though, I've suggested an immediate rollout with a placeholder<= +br> +client timeout instead of the HF code initially in order to accelerate<br> +that.<br> +<span class=3D"">><br> +>> Since this BIP<br> +>> only activates with a clear miner majority it should not increase = +the<br> +>> risk of an extended chain split.<br> +><br> +> The concern I'm raising is more about the psychology of giving BIP= +148<br> +> a sense of safety that may not be valid.=C2=A0 Without several more st= +eps,<br> +> BIP148 is definitely on track to be a risky chainsplit, and without<br= +> +> segwit2x it will almost certainly be a small minority chain. (Unless<b= +r> +> the segwit2x compromise falls apart before then, and even in that case= +<br> +> it is likely to be a minority chain)<br> +</span>There are 2 primary factors involved here, economic support and<br> +hashpower either of which is enough to make a permanent chain split<br> +unlikely, miners will mine whichever chain is most profitable(see<br> +ETH/ETC hashpower profitability equilibrium for an example of how this<br> +works in practice) however there may be lag time immediately after the<br> +split if there is an economic majority but not a hashpower majority<br> +initially. This is risk mitigation that only requires miners support<br> +however. The main issue is just one of activation timelines, BIP91 as<br> +is takes too long to activate unless started ahead of the existing<br> +segwit2x schedule and it's unlikely that BIP148 will get pushed back<br= +> +any further.<br> +<div class=3D"HOEnZb"><div class=3D"h5">><br> +> Jared<br> +><br> +><br> +> On Wed, Jun 7, 2017 at 2:42 PM, James Hilliard<br> +> <<a href=3D"mailto:james.hilliard1@gmail.com">james.hilliard1@gmail= +.com</a>> wrote:<br> +>> I don't really see how this would increase the likelihood of a= +n<br> +>> extended chain split assuming BIP148 is going to have<br> +>> non-insignificant economic backing. This BIP is designed to provid= +e a<br> +>> risk mitigation measure that miners can safely deploy. Since this = +BIP<br> +>> only activates with a clear miner majority it should not increase = +the<br> +>> risk of an extended chain split. At this point it is not completel= +y<br> +>> clear how much economic support there is for BIP148 but support<br= +> +>> certainly seems to be growing and we have nearly 2 months until BI= +P148<br> +>> activation. I intentionally used a shorter activation period here = +so<br> +>> that decisions by miners can be made close to the BIP148 activatio= +n<br> +>> date.<br> +>><br> +>> On Wed, Jun 7, 2017 at 4:29 PM, Jared Lee Richardson <<a href= +=3D"mailto:jaredr26@gmail.com">jaredr26@gmail.com</a>> wrote:<br> +>>> I think this BIP represents a gamble, and the gamble may not b= +e a good<br> +>>> one.=C2=A0 The gamble here is that if the segwit2x changes are= + rolled out<br> +>>> on time, and if the signatories accept the bit4 + bit1 signali= +ng<br> +>>> proposals within BIP91, the launch will go smoother, as intend= +ed.=C2=A0 But<br> +>>> conversely, if either the segwit2x signatories balk about the = +Bit1<br> +>>> signaling OR if the timelines for segwit2mb are missed even by= + a bit,<br> +>>> it may cause the BIP148 chainsplit to be worse than it would b= +e<br> +>>> without.=C2=A0 Given the frequent concerns raised in multiple = +places about<br> +>>> the aggressiveness of the segwit2x timelines, including the<br= +> +>>> non-hardfork timelines, this does not seem like a great gamble= + to be<br> +>>> making.<br> +>>><br> +>>> The reason I say it may make the chainsplit be worse than it w= +ould<br> +>>> otherwise be is that it may provide a false sense of safety fo= +r BIP148<br> +>>> that currently does not currently exist(and should not, as it = +is a<br> +>>> chainsplit).=C2=A0 That sense of safety would only be legitima= +te if the<br> +>>> segwit2x signatories were on board, and the segwit2x code effe= +ctively<br> +>>> enforced BIP148 simultaneously, neither of which are guarantee= +d.=C2=A0 If<br> +>>> users and more miners had a false sense that BIP148 was *not* = +going to<br> +>>> chainsplit from default / segwit2x, they might not follow the = +news if<br> +>>> suddenly the segwit2x plan were delayed for a few days.=C2=A0 = +While any<br> +>>> additional support would definitely be cheered on by BIP148<br= +> +>>> supporters, the practical reality might be that this proposal = +would<br> +>>> take BIP148 from the "unlikely to have any viable chain a= +fter flag day<br> +>>> without segwit2x" category into the "small but viabl= +e minority chain"<br> +>>> category, and even worse, it might strengthen the chainsplit j= +ust days<br> +>>> before segwit is activated on BOTH chains, putting the BIP148<= +br> +>>> supporters on the wrong pro-segwit, but still-viable chain.<br= +> +>>><br> +>>> If Core had taken a strong stance to include BIP148 into the c= +lient,<br> +>>> and if BIP148 support were much much broader, I would feel dif= +ferently<br> +>>> as the gamble would be more likely to discourage a chainsplit = +(By<br> +>>> forcing the acceleration of segwit2x) rather than encourage it= + (by<br> +>>> strengthening an extreme minority chainsplit that may wind up = +on the<br> +>>> wrong side of two segwit-activated chains).=C2=A0 As it stands= + now, this<br> +>>> seems like a very dangerous attempt to compromise with a small= + but<br> +>>> vocal group that are the ones creating the threat to begin wit= +h.<br> +>>><br> +>>> Jared<br> +>>><br> +>>> On Tue, Jun 6, 2017 at 5:56 PM, James Hilliard via bitcoin-dev= +<br> +>>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b= +itcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br> +>>>> Due to the proposed calendar(<a href=3D"https://segwit2x.g= +ithub.io/" rel=3D"noreferrer" target=3D"_blank">https://segwit2x.<wbr>githu= +b.io/</a>) for the<br> +>>>> SegWit2x agreement being too slow to activate SegWit manda= +tory<br> +>>>> signalling ahead of BIP148 using BIP91 I would like to pro= +pose another<br> +>>>> option that miners can use to prevent a chain split ahead = +of the Aug<br> +>>>> 1st BIP148 activation date.<br> +>>>><br> +>>>> The splitprotection soft fork is essentially BIP91 but usi= +ng BIP8<br> +>>>> instead of BIP9 with a lower activation threshold and imme= +diate<br> +>>>> mandatory signalling lock-in. This allows for a majority o= +f miners to<br> +>>>> activate mandatory SegWit signalling and prevent a potenti= +al chain<br> +>>>> split ahead of BIP148 activation.<br> +>>>><br> +>>>> This BIP allows for miners to respond to market forces qui= +ckly ahead<br> +>>>> of BIP148 activation by signalling for splitprotection. An= +y miners<br> +>>>> already running BIP148 should be encouraged to use splitpr= +otection.<br> +>>>><br> +>>>> <pre><br> +>>>>=C2=A0 =C2=A0BIP: splitprotection<br> +>>>>=C2=A0 =C2=A0Layer: Consensus (soft fork)<br> +>>>>=C2=A0 =C2=A0Title: User Activated Soft Fork Split Protecti= +on<br> +>>>>=C2=A0 =C2=A0Author: James Hilliard <<a href=3D"mailto:j= +ames.hilliard1@gmail.com">james.hilliard1@gmail.com</a>><br> +>>>>=C2=A0 =C2=A0Comments-Summary: No comments yet.<br> +>>>>=C2=A0 =C2=A0Comments-URI:<br> +>>>>=C2=A0 =C2=A0Status: Draft<br> +>>>>=C2=A0 =C2=A0Type: Standards Track<br> +>>>>=C2=A0 =C2=A0Created: 2017-05-22<br> +>>>>=C2=A0 =C2=A0License: BSD-3-Clause<br> +>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CC0-1.0<br> +>>>> </pre><br> +>>>><br> +>>>> =3D=3DAbstract=3D=3D<br> +>>>><br> +>>>> This document specifies a coordination mechanism for a sim= +ple majority<br> +>>>> of miners to prevent a chain split ahead of BIP148 activat= +ion.<br> +>>>><br> +>>>> =3D=3DDefinitions=3D=3D<br> +>>>><br> +>>>> "existing segwit deployment" refer to the BIP9 &= +quot;segwit" deployment<br> +>>>> using bit 1, between November 15th 2016 and November 15th = +2017 to<br> +>>>> activate BIP141, BIP143 and BIP147.<br> +>>>><br> +>>>> =3D=3DMotivation=3D=3D<br> +>>>><br> +>>>> The biggest risk of BIP148 is an extended chain split, thi= +s BIP<br> +>>>> provides a way for a simple majority of miners to eliminat= +e that risk.<br> +>>>><br> +>>>> This BIP provides a way for a simple majority of miners to= + coordinate<br> +>>>> activation of the existing segwit deployment with less tha= +n 95%<br> +>>>> hashpower before BIP148 activation. Due to time constraint= +s unless<br> +>>>> immediately deployed BIP91 will likely not be able to enfo= +rce<br> +>>>> mandatory signalling of segwit before the Aug 1st activati= +on of<br> +>>>> BIP148. This BIP provides a method for rapid miner activat= +ion of<br> +>>>> SegWit mandatory signalling ahead of the BIP148 activation= + date. Since<br> +>>>> the primary goal of this BIP is to reduce the chance of an= + extended<br> +>>>> chain split as much as possible we activate using a simple= + miner<br> +>>>> majority of 65% over a 504 block interval rather than a hi= +gher<br> +>>>> percentage. This BIP also allows miners to signal their in= +tention to<br> +>>>> run BIP148 in order to prevent a chain split.<br> +>>>><br> +>>>> =3D=3DSpecification=3D=3D<br> +>>>><br> +>>>> While this BIP is active, all blocks must set the nVersion= + header top<br> +>>>> 3 bits to 001 together with bit field (1<<1) (accord= +ing to the<br> +>>>> existing segwit deployment). Blocks that do not signal as = +required<br> +>>>> will be rejected.<br> +>>>><br> +>>>> =3D=3DDeployment=3D=3D<br> +>>>><br> +>>>> This BIP will be deployed by "version bits" with= + a 65%(this can be<br> +>>>> adjusted if desired) activation threshold BIP9 with the na= +me<br> +>>>> "splitprotecion" and using bit 2.<br> +>>>><br> +>>>> This BIP starts immediately and is a BIP8 style soft fork = +since<br> +>>>> mandatory signalling will start on midnight August 1st 201= +7 (epoch<br> +>>>> time 1501545600) regardless of whether or not this BIP has= + reached its<br> +>>>> own signalling threshold. This BIP will cease to be active= + when segwit<br> +>>>> is locked-in.<br> +>>>><br> +>>>> =3D=3D=3D Reference implementation =3D=3D=3D<br> +>>>><br> +>>>> <pre><br> +>>>> // Check if Segregated Witness is Locked In<br> +>>>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, cons= +t<br> +>>>> Consensus::Params& params)<br> +>>>> {<br> +>>>>=C2=A0 =C2=A0 =C2=A0LOCK(cs_main);<br> +>>>>=C2=A0 =C2=A0 =C2=A0return (VersionBitsState(pindexPrev, pa= +rams,<br> +>>>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) =3D=3D<br> +>>>> THRESHOLD_LOCKED_IN);<br> +>>>> }<br> +>>>><br> +>>>> // SPLITPROTECTION mandatory segwit signalling.<br> +>>>> if ( VersionBitsState(pindex-><wbr>pprev, chainparams.G= +etConsensus(),<br> +>>>> Consensus::DEPLOYMENT_<wbr>SPLITPROTECTION, versionbitscac= +he) =3D=3D<br> +>>>> THRESHOLD_LOCKED_IN &&<br> +>>>>=C2=A0 =C2=A0 =C2=A0 !IsWitnessLockedIn(pindex-><wbr>ppr= +ev, chainparams.GetConsensus()) &&<br> +>>>> // Segwit is not locked in<br> +>>>>=C2=A0 =C2=A0 =C2=A0 !IsWitnessEnabled(pindex-><wbr>ppre= +v, chainparams.GetConsensus()) ) //<br> +>>>> and is not active.<br> +>>>> {<br> +>>>>=C2=A0 =C2=A0 =C2=A0bool fVersionBits =3D (pindex->nVers= +ion & VERSIONBITS_TOP_MASK) =3D=3D<br> +>>>> VERSIONBITS_TOP_BITS;<br> +>>>>=C2=A0 =C2=A0 =C2=A0bool fSegbit =3D (pindex->nVersion &= +amp;<br> +>>>> VersionBitsMask(chainparams.<wbr>GetConsensus(),<br> +>>>> Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;<br> +>>>>=C2=A0 =C2=A0 =C2=A0if (!(fVersionBits && fSegbit))= + {<br> +>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return state.DoS(0, error= +("ConnectBlock(): relayed block must<br> +>>>> signal for segwit, please upgrade"), REJECT_INVALID, = +"bad-no-segwit");<br> +>>>>=C2=A0 =C2=A0 =C2=A0}<br> +>>>> }<br> +>>>><br> +>>>> // BIP148 mandatory segwit signalling.<br> +>>>> int64_t nMedianTimePast =3D pindex->GetMedianTimePast()= +;<br> +>>>> if ( (nMedianTimePast >=3D 1501545600) &&=C2=A0= + // Tue 01 Aug 2017 00:00:00 UTC<br> +>>>>=C2=A0 =C2=A0 =C2=A0 (nMedianTimePast <=3D 1510704000) &= +amp;&=C2=A0 // Wed 15 Nov 2017 00:00:00 UTC<br> +>>>>=C2=A0 =C2=A0 =C2=A0 (!IsWitnessLockedIn(pindex-><wbr>pp= +rev, chainparams.GetConsensus()) &&<br> +>>>>=C2=A0 // Segwit is not locked in<br> +>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0!IsWitnessEnabled(pindex-><wb= +r>pprev, chainparams.GetConsensus())) )<br> +>>>>=C2=A0 // and is not active.<br> +>>>> {<br> +>>>>=C2=A0 =C2=A0 =C2=A0bool fVersionBits =3D (pindex->nVers= +ion & VERSIONBITS_TOP_MASK) =3D=3D<br> +>>>> VERSIONBITS_TOP_BITS;<br> +>>>>=C2=A0 =C2=A0 =C2=A0bool fSegbit =3D (pindex->nVersion &= +amp;<br> +>>>> VersionBitsMask(chainparams.<wbr>GetConsensus(),<br> +>>>> Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;<br> +>>>>=C2=A0 =C2=A0 =C2=A0if (!(fVersionBits && fSegbit))= + {<br> +>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return state.DoS(0, error= +("ConnectBlock(): relayed block must<br> +>>>> signal for segwit, please upgrade"), REJECT_INVALID, = +"bad-no-segwit");<br> +>>>>=C2=A0 =C2=A0 =C2=A0}<br> +>>>> }<br> +>>>> </pre><br> +>>>><br> +>>>> <a href=3D"https://github.com/bitcoin/bitcoin/compare/0.14= +...jameshilliard:splitprotection-v0.14.1" rel=3D"noreferrer" target=3D"_bla= +nk">https://github.com/bitcoin/<wbr>bitcoin/compare/0.14...<wbr>jameshillia= +rd:splitprotection-<wbr>v0.14.1</a><br> +>>>><br> +>>>> =3D=3DBackwards Compatibility=3D=3D<br> +>>>><br> +>>>> This deployment is compatible with the existing "segw= +it" bit 1<br> +>>>> deployment scheduled between midnight November 15th, 2016 = +and midnight<br> +>>>> November 15th, 2017. This deployment is also compatible wi= +th the<br> +>>>> existing BIP148 deployment. This BIP is compatible with BI= +P91 only if<br> +>>>> BIP91 activates before it and before BIP148. Miners will n= +eed to<br> +>>>> upgrade their nodes to support splitprotection otherwise t= +hey may<br> +>>>> build on top of an invalid block. While this bip is active= + users<br> +>>>> should either upgrade to splitprotection or wait for addit= +ional<br> +>>>> confirmations when accepting payments.<br> +>>>><br> +>>>> =3D=3DRationale=3D=3D<br> +>>>><br> +>>>> Historically we have used IsSuperMajority() to activate so= +ft forks<br> +>>>> such as BIP66 which has a mandatory signalling requirement= + for miners<br> +>>>> once activated, this ensures that miners are aware of new = +rules being<br> +>>>> enforced. This technique can be leveraged to lower the sig= +nalling<br> +>>>> threshold of a soft fork while it is in the process of bei= +ng deployed<br> +>>>> in a backwards compatible way. We also use a BIP8 style ti= +meout to<br> +>>>> ensure that this BIP is compatible with BIP148 and that BI= +P148<br> +>>>> compatible mandatory signalling activates regardless of mi= +ner<br> +>>>> signalling levels.<br> +>>>><br> +>>>> By orphaning non-signalling blocks during the BIP9 bit 1 &= +quot;segwit"<br> +>>>> deployment, this BIP can cause the existing "segwit&q= +uot; deployment to<br> +>>>> activate without needing to release a new deployment. As w= +e approach<br> +>>>> BIP148 activation it may be desirable for a majority of mi= +ners to have<br> +>>>> a method that will ensure that there is no chain split.<br= +> +>>>><br> +>>>> =3D=3DReferences=3D=3D<br> +>>>><br> +>>>> *[<a href=3D"https://lists.linuxfoundation.org/pipermail/b= +itcoin-dev/2017-March/013714.html" rel=3D"noreferrer" target=3D"_blank">htt= +ps://lists.<wbr>linuxfoundation.org/pipermail/<wbr>bitcoin-dev/2017-March/0= +13714.<wbr>html</a><br> +>>>> Mailing list discussion]<br> +>>>> *[<a href=3D"https://github.com/bitcoin/bitcoin/blob/v0.6.= +0/src/main.cpp#L1281-L1283" rel=3D"noreferrer" target=3D"_blank">https://gi= +thub.com/bitcoin/<wbr>bitcoin/blob/v0.6.0/src/main.<wbr>cpp#L1281-L1283</a>= +<br> +>>>> P2SH flag day activation]<br> +>>>> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and d= +elay]]<br> +>>>> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]<br> +>>>> *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]= +]<br> +>>>> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus= + layer)]]<br> +>>>> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verific= +ation for<br> +>>>> Version 0 Witness Program]]<br> +>>>> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack elem= +ent malleability]]<br> +>>>> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwi= +t deployment]]<br> +>>>> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second de= +ployment)]]<br> +>>>> *[<a href=3D"https://bitcoincore.org/en/2016/01/26/segwit-= +benefits/" rel=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/en/= +<wbr>2016/01/26/segwit-benefits/</a> Segwit benefits]<br> +>>>><br> +>>>> =3D=3DCopyright=3D=3D<br> +>>>><br> +>>>> This document is dual licensed as BSD 3-clause, and Creati= +ve Commons<br> +>>>> CC0 1.0 Universal.<br> +>>>> ______________________________<wbr>_________________<br> +>>>> bitcoin-dev mailing list<br> +>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b= +itcoin-dev@lists.<wbr>linuxfoundation.org</a><br> +>>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listi= +nfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo= +undation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> +</div></div></blockquote></div><br></div> + +--001a11457cc2f8847c055166995d-- + |