summaryrefslogtreecommitdiff
path: root/63
diff options
context:
space:
mode:
authorJared Lee Richardson <jaredr26@gmail.com>2017-06-07 14:09:04 -0700
committerbitcoindev <bitcoindev@gnusha.org>2017-06-07 21:09:08 +0000
commite56365d9cb1133ab8e22372aea96d1176412b1ad (patch)
tree252fea4ad061991aa0d96d27156c13ab7456352b /63
parent3b1aefcf84b30b1782f01e148e0b33dd63c6df21 (diff)
downloadpi-bitcoindev-e56365d9cb1133ab8e22372aea96d1176412b1ad.tar.gz
pi-bitcoindev-e56365d9cb1133ab8e22372aea96d1176412b1ad.zip
Re: [bitcoin-dev] User Activated Soft Fork Split Protection
Diffstat (limited to '63')
-rw-r--r--63/8f03db65cdfb2a81843d82516616ca7c7da04d406
1 files changed, 406 insertions, 0 deletions
diff --git a/63/8f03db65cdfb2a81843d82516616ca7c7da04d b/63/8f03db65cdfb2a81843d82516616ca7c7da04d
new file mode 100644
index 000000000..35dbab3e8
--- /dev/null
+++ b/63/8f03db65cdfb2a81843d82516616ca7c7da04d
@@ -0,0 +1,406 @@
+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 E03479C
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 7 Jun 2017 21:09:08 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com
+ [209.85.213.50])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19BB8108
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 7 Jun 2017 21:09:06 +0000 (UTC)
+Received: by mail-vk0-f50.google.com with SMTP id p62so10140625vkp.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 07 Jun 2017 14:09:05 -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:content-transfer-encoding;
+ bh=De4y6Rd4AUKdhbF3htn8sLuo/XZQIa7NeTOs8TujJEs=;
+ b=JD0+UhPkcupVGzvEqCt21livOLqM1hpTYabsmeM0nyqBVOKWZoZ28DVS1qw9UajEfh
+ T7A6xDGO46Ttr2MDjZa+ATUlPAPjKRVOxZlrff8NBEodpaAjkQ0YIjupobCFm15w2raK
+ NObMZrMftRNk5PZMACGXif1oLb3VdVCWj6an3a35TGqtUPD2ulp9BhDdbgDdHuKOyVJO
+ MZrVxZbUVACD5xn2DyDRMbgAESZDDsssJdKYTXY4saY16g+YZPW5qGAxGEgJWcIBcQ/t
+ R0DpL7J/lBOgWqwO4HKDeCV1qfCIJQZc6QxGfWZOXDL4Lcimgg6RRyF1xVAEuqeIYl0Z
+ O54g==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:in-reply-to:references:from:date
+ :message-id:subject:to:cc:content-transfer-encoding;
+ bh=De4y6Rd4AUKdhbF3htn8sLuo/XZQIa7NeTOs8TujJEs=;
+ b=GCtqq5Y191yEtQfGE86qfEo2nZpJDqo4nHJ9LLK2c0WhKjagsMyzsUjn49fz/g3AwR
+ /6Cf9o/NN7HQDwfUH6tOdchj8wJnpJzvVHJuW3XWSj/sHXdcGLjWt5bgS3Um+Ulolit9
+ uC/f6ikIa7qT5+dIt/dhtzgBmL5ZA5NvrJ1ev1noyPD+X5KcL1Qx0MRNEcbOwaac5Z0W
+ lRhuyZVGWLLORu8nA5P54yer041JTpf+9ExXPed/fDkoqLKFnadJQDU31Nq7x8oDEd9Y
+ BRBABeK70WhKlpMWKNVc0drV3b7+bM3FB90gs47gYDZYaw57i8Mrfw4KYcLSTWth0qmI
+ rP4w==
+X-Gm-Message-State: AODbwcDjeSMjdpRMHaEKP4UhvwSXzBDoehuc3OmIBw78FSOMve8x6m6A
+ /QCcEFDPFYMN89kG/ThpGXgETdxlXw==
+X-Received: by 10.31.2.204 with SMTP id 195mr13585529vkc.65.1496869745050;
+ Wed, 07 Jun 2017 14:09:05 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.31.157.215 with HTTP; Wed, 7 Jun 2017 14:09:04 -0700 (PDT)
+In-Reply-To: <CAJowKgJi-68G5Xy1_8n_BOX5e8myj08_SPiFu+cdWsRD4DNy4w@mail.gmail.com>
+References: <CADvTj4qpH-t5Gx6qyn3yToyUE_GFaBE989=AWNHLKMpMNW3R+w@mail.gmail.com>
+ <AE5BA251-9DA6-4E34-A748-11C8CF91977C@taoeffect.com>
+ <CADvTj4q+oOS=DKfpiNQ6PAbksQfa1gKNfokr2Zc6PNGWqLyL4A@mail.gmail.com>
+ <0CDEF5A2-0BAF-46E4-8906-39D4724AF3F2@taoeffect.com>
+ <CADvTj4oJr38V+b=96pt7GiaMMSPujsz9wQ-5wmgM=rvWUC8Dkw@mail.gmail.com>
+ <CAJowKgJi-68G5Xy1_8n_BOX5e8myj08_SPiFu+cdWsRD4DNy4w@mail.gmail.com>
+From: Jared Lee Richardson <jaredr26@gmail.com>
+Date: Wed, 7 Jun 2017 14:09:04 -0700
+Message-ID: <CAD1TkXvaNq8wBsDdbYG4Qwn9YY=tXw8kPQQ2=B4nLKPdq3fsWg@mail.gmail.com>
+To: Erik Aronesty <erik@q32.com>
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+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,
+ 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 21:45:04 +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 21:09:09 -0000
+
+> This is, by far, the safest way for miners to quickly defend against a ch=
+ain split, much better than a -bip148 option. This allows miners to defen=
+d themselves, with very little risk, since the defense is only activated if=
+ the majority of miners do so. I would move for a very rapid deployment. =
+Only miners would need to upgrade. Regular users would not have to concer=
+n themselves with this release.
+
+FYI, even if very successful, this deployment and change may have a
+severe negative impact on a small group of miners. Any miners/pools
+who are not actively following the forums, news, or these discussions
+may be difficult to reach and communicate with in time, particularly
+with language barriers. Of those, any who are also either not
+signaling segwit currently or are running an older software version
+will have their blocks continuously and constantly orphaned, but may
+not have any alarms or notifications set up for such an unexpected
+failure. That may or may not be a worthy consideration, but it is
+definitely brusque and a harsh price to pay. Considering the
+opposition mentioned against transaction limits for the rare cases
+where a very large transaction has already been signed, it seems that
+this would be worthy of consideration. For the few miners in that
+situation, it does turn segwit from an optional softfork into a
+punishing hardfork.
+
+I don't think that's a sufficient reason alone to kill the idea, but
+it should be a concern.
+
+Jared
+
+On Wed, Jun 7, 2017 at 7:10 AM, Erik Aronesty via bitcoin-dev
+<bitcoin-dev@lists.linuxfoundation.org> wrote:
+> This is, by far, the safest way for miners to quickly defend against a ch=
+ain
+> split, much better than a -bip148 option. This allows miners to defend
+> themselves, with very little risk, since the defense is only activated if
+> the majority of miners do so. I would move for a very rapid deployment.
+> Only miners would need to upgrade. Regular users would not have to conc=
+ern
+> themselves with this release.
+>
+> On Wed, Jun 7, 2017 at 6:13 AM, James Hilliard via bitcoin-dev
+> <bitcoin-dev@lists.linuxfoundation.org> wrote:
+>>
+>> I think even 55% would probably work out fine simply due to incentive
+>> structures, once signalling is over 51% it's then clear to miners that
+>> non-signalling blocks will be orphaned and the rest will rapidly
+>> update to splitprotection/BIP148. The purpose of this BIP is to reduce
+>> chain split risk for BIP148 since it's looking like BIP148 is going to
+>> be run by a non-insignificant percentage of the economy at a minimum.
+>>
+>> On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <contact@taoeffect.com> wrot=
+e:
+>> > See thread on replay attacks for why activating regardless of threshol=
+d
+>> > is a
+>> > bad idea [1].
+>> >
+>> > BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it mor=
+e
+>> > difficult for miners to hold together in opposition to Core. It gives
+>> > Core
+>> > more leverage in negotiations.
+>> >
+>> > If they don't activate with 80%, Core can release another BIP to reduc=
+e
+>> > it
+>> > to 75%.
+>> >
+>> > Each threshold reduction makes it both more likely to succeed, but als=
+o
+>> > increases the likelihood of harm to the ecosystem.
+>> >
+>> > Cheers,
+>> > Greg
+>> >
+>> > [1]
+>> >
+>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/0144=
+97.html
+>> >
+>> > --
+>> > Please do not email me anything that you are not comfortable also
+>> > sharing
+>> > with the NSA.
+>> >
+>> > On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1@gmail.com>
+>> > wrote:
+>> >
+>> > This is a BIP8 style soft fork so mandatory signalling will be active
+>> > after Aug 1st regardless.
+>> >
+>> > On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact@taoeffect.com>
+>> > wrote:
+>> >
+>> > What is the probability that a 65% threshold is too low and can allow =
+a
+>> > "surprise miner attack", whereby miners are kept offline before the
+>> > deadline, and brought online immediately after, creating potential
+>> > havoc?
+>> >
+>> > (Nit: "simple majority" usually refers to >50%, I think, might cause
+>> > confusion.)
+>> >
+>> > -Greg Slepak
+>> >
+>> > --
+>> > Please do not email me anything that you are not comfortable also
+>> > sharing
+>> > with the NSA.
+>> >
+>> > On 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>
+>> >
+>> > =3D=3DAbstract=3D=3D
+>> >
+>> > This document specifies a coordination mechanism for a simple majority
+>> > of miners to prevent a chain split ahead of BIP148 activation.
+>> >
+>> > =3D=3DDefinitions=3D=3D
+>> >
+>> > "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.
+>> >
+>> > =3D=3DMotivation=3D=3D
+>> >
+>> > 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.
+>> >
+>> > =3D=3DSpecification=3D=3D
+>> >
+>> > 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.
+>> >
+>> > =3D=3DDeployment=3D=3D
+>> >
+>> > 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.
+>> >
+>> > =3D=3D=3D Reference implementation =3D=3D=3D
+>> >
+>> > <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) =3D=3D
+>> > THRESHOLD_LOCKED_IN);
+>> > }
+>> >
+>> > // SPLITPROTECTION mandatory segwit signalling.
+>> > if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
+>> > Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) =3D=3D
+>> > THRESHOLD_LOCKED_IN &&
+>> > !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
+>> > // Segwit is not locked in
+>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
+>> > and is not active.
+>> > {
+>> > bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=
+=3D
+>> > VERSIONBITS_TOP_BITS;
+>> > bool fSegbit =3D (pindex->nVersion &
+>> > VersionBitsMask(chainparams.GetConsensus(),
+>> > Consensus::DEPLOYMENT_SEGWIT)) !=3D 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 =3D pindex->GetMedianTimePast();
+>> > if ( (nMedianTimePast >=3D 1501545600) && // Tue 01 Aug 2017 00:00:00=
+ UTC
+>> > (nMedianTimePast <=3D 1510704000) && // Wed 15 Nov 2017 00:00:00 U=
+TC
+>> > (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
+>> > // Segwit is not locked in
+>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
+>> > // and is not active.
+>> > {
+>> > bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=
+=3D
+>> > VERSIONBITS_TOP_BITS;
+>> > bool fSegbit =3D (pindex->nVersion &
+>> > VersionBitsMask(chainparams.GetConsensus(),
+>> > Consensus::DEPLOYMENT_SEGWIT)) !=3D 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:splitp=
+rotection-v0.14.1
+>> >
+>> > =3D=3DBackwards Compatibility=3D=3D
+>> >
+>> > 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.
+>> >
+>> > =3D=3DRationale=3D=3D
+>> >
+>> > 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.
+>> >
+>> > =3D=3DReferences=3D=3D
+>> >
+>> >
+>> > *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/0=
+13714.html
+>> > Mailing list discussion]
+>> >
+>> > *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1=
+283
+>> > 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]
+>> >
+>> > =3D=3DCopyright=3D=3D
+>> >
+>> > 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
+>> >
+>> >
+>> >
+>> _______________________________________________
+>> bitcoin-dev mailing list
+>> bitcoin-dev@lists.linuxfoundation.org
+>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+>
+>
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-28 22:36:38 +0000