summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSteven Pine <steven.pine@gmail.com>2017-05-23 00:03:49 -0400
committerbitcoindev <bitcoindev@gnusha.org>2017-05-23 04:03:54 +0000
commit5157da8e16c0b8406a3225719b0d1047ac0b5305 (patch)
tree7ec2b602a1340d4e8939356b443257817f9315ff
parent0ba404563fb4fdde32c48d91caaa3e27f95c8968 (diff)
downloadpi-bitcoindev-5157da8e16c0b8406a3225719b0d1047ac0b5305.tar.gz
pi-bitcoindev-5157da8e16c0b8406a3225719b0d1047ac0b5305.zip
Re: [bitcoin-dev] I do not support the BIP 148 UASF
-rw-r--r--2a/bfaffbe8a2fbde294cb1c77f45b46596323637507
1 files changed, 507 insertions, 0 deletions
diff --git a/2a/bfaffbe8a2fbde294cb1c77f45b46596323637 b/2a/bfaffbe8a2fbde294cb1c77f45b46596323637
new file mode 100644
index 000000000..7448c36e0
--- /dev/null
+++ b/2a/bfaffbe8a2fbde294cb1c77f45b46596323637
@@ -0,0 +1,507 @@
+Return-Path: <steven.pine@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 1AF0E721
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 23 May 2017 04:03:54 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com
+ [209.85.128.180])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 37F09171
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 23 May 2017 04:03:52 +0000 (UTC)
+Received: by mail-wr0-f180.google.com with SMTP id z52so48980373wrc.2
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 22 May 2017 21:03:52 -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=oc3jGjMyb6NWsiry2dsuW5CeMSex4+vgBWkrKTr4Xjw=;
+ b=HQL6eIxKEKW80otwhKogrNPjUBtUgf2z5PMqvWwkD50iBuSqSP4lbGzo/ZMySWRme1
+ HtB9E/C1Ld118FT2j/GLySmhnPBHRJfHEgfojmPZotQ9f+FODfMGZmUZVMBCeMG/bm9r
+ Nrk5HJxhIC0OqD09xJ033a23U5UR7IkkNPkNwRIbeqAohjvSryFPDBZnlQQ5NP9yzd3s
+ lAjJx1p5GQPwbAj+kQMYQXxBk7M7Zx1+tIbvpUA3psIUuD1cWVCvFj1WM4oyg+wIf1M9
+ nPyAZ4OuTddMdPheZ55iKnr+wwv4qghM13Hz6rAZdQFjQiikyC+i90pQf1KcIA1vBZgN
+ cPiQ==
+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=oc3jGjMyb6NWsiry2dsuW5CeMSex4+vgBWkrKTr4Xjw=;
+ b=YjljqHXh77+yCgpFeHTVAvd5jmMCP5DNbqdnzLqDiZr3enN2ahH5Z+ChmwwHQwSFU6
+ sIt9SkOM9vy9tb8tHzkDzRRoPbENw4hnbTbM1Dni89zUl1Y/wRNMK1wuRa3rGFHSJjn5
+ tNuZT+ZaBB29h+asbK81ZyZTHqjgY5ec+KKfsrjfAsLu67tTo3U1rGXNIfcj41fTfn88
+ 2ILGqnd7V9OKM6Tf5h3IfFyhr2l/oR9qEwQ9gYGi7igtAk03P8qgx/NaTHJ7isxatdBD
+ kq4OvuMYhQK9vN22zNiosm4RXG8STQ2bNVBECMnCCzULFw11PXInOyV/Yhlv0d3iNIDF
+ 8+mw==
+X-Gm-Message-State: AODbwcBgKgFGxLRipsdi2yzHezhQPJlVSOgH8q/MJYiZJq56CK7tt9vF
+ 9HCLTXRTA+oK48tPwlb3MNFU3An6PA==
+X-Received: by 10.223.161.65 with SMTP id r1mr15561221wrr.114.1495512230849;
+ Mon, 22 May 2017 21:03:50 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.28.107.27 with HTTP; Mon, 22 May 2017 21:03:49 -0700 (PDT)
+In-Reply-To: <CAFp6fsGcKip_R7OH217mXBQ8OK9N_3Ea-1HtRin3EtwzvJaBhQ@mail.gmail.com>
+References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
+ <CAFp6fsGcKip_R7OH217mXBQ8OK9N_3Ea-1HtRin3EtwzvJaBhQ@mail.gmail.com>
+From: Steven Pine <steven.pine@gmail.com>
+Date: Tue, 23 May 2017 00:03:49 -0400
+Message-ID: <CAAjy6kC43DX3wpaZ+3skBUO8hVrYt7uNZfw1Ep3GDJs8YA9Gxg@mail.gmail.com>
+To: Suhas Daftuar <sdaftuar@gmail.com>
+Content-Type: multipart/alternative; boundary="f403045e39de46f28a0550291394"
+X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
+ RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+X-Mailman-Approved-At: Tue, 23 May 2017 06:06:56 +0000
+Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
+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: Tue, 23 May 2017 04:03:54 -0000
+
+--f403045e39de46f28a0550291394
+Content-Type: text/plain; charset="UTF-8"
+
+I'm glad some discussion has been moved back here.
+
+Correct me if I am wrong, but currently core developers are arguing over
+whether or not to allow an optional configuration switch which defaults off
+but signals and enforces BIP148 when used. Who are we protecting users
+from, themselves? Are you protecting core? from what? I am somewhat
+genuinely befuddled by those who can't even allow a user config switch to
+be set.
+
+I guess I find it all incredibly silly, but perhaps I suffer from some
+basic confusion.
+
+
+
+On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> I also do not support the BIP 148 UASF, and I'd like to add to the points
+> that Greg has already raised in this thread.
+>
+> BIP 148 would introduce a new consensus rule that softforks out non-segwit
+> signalling blocks in some time period. I reject this consensus rule as
+> both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to
+> reach consensus on the state of a shared ledger, and even though I think
+> the Bitcoin network ought to adopt segwit, I don't think that concern
+> trumps the goal of not splitting the network.
+>
+> Many BIP 148 advocates seem to start with the assumption that segwit
+> already has a lot of support, and suggest that BIP 148 does as well.
+> However I don't think it's fair or correct to separate the activation
+> proposal for segwit from the rest of the segwit proposal. The deployment
+> parameters for segwit are consensus-critical; assuming that some other
+> deployment has consensus because it would result in the rest of the segwit
+> proposal activating is an unjustified leap.
+>
+> Even if there were no feasible alternate segwit deployment method
+> available to us, I would hesitate to recommend that the network adopt a
+> potentially consensus-splitting approach, even though I firmly believe that
+> the ideas behind segwit are fundamentally good ones. But fortunately that
+> is not the situation we are in; we have substantially less disruptive
+> methods available to us to activate it, even if the current BIP 9
+> deployment were to fail -- such as another BIP 9 deployment in the future,
+> or perhaps a BIP 149 deployment.
+>
+> If we do pursue a "user-activated" deployment of segwit, I'd recommend
+> that we do so in a more careful way than BIP 148 or 149 currently suggest,
+> which as I understand would otherwise make very few changes to the current
+> implementation. However, due to the BIP 9 activation assumption, the
+> Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
+> the idea that miners would both enforce the rules and mine segwit blocks.
+> However, we can separate these concerns, as we started to do in the Bitcoin
+> Core 0.14.1 release, where mining segwit blocks is not required in order to
+> generally mine or signal for segwit in the software. And we can go further
+> still: without too much work, we could make further improvements to
+> accommodate miners who, for whatever reason, don't want to upgrade their
+> systems, such as by improving block relay from pre-segwit peers [1], or
+> optimizing transaction selection for miners who are willing to enforce the
+> segwit rules but haven't upgraded their systems to mine segwit blocks [2].
+>
+> If we would seek to activate a soft-fork with less clear miner signaling
+> (such as BIP 149), then I think such improvements are warranted to minimize
+> network disruption. In general, we should not seek to censor hashpower on
+> the network unless we have a very important reason for doing so. While the
+> issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
+> proposal on the spectrum of "censorship attack on Bitcoin" to "benign
+> protocol upgrade", BIP 148 strikes me as closer to the former than the
+> latter. There is simply no need here to orphan these non-signalling blocks
+> that could otherwise be used to secure the network.
+>
+> To go further: I think BIP 148 is ill-conceived even for achieving its own
+> presumed goals -- the motivation for adding a consensus rule that applies
+> to the version bits on blocks is surely for the effect such bits have on
+> older software, such as Bitcoin Core releases 0.13.1 and later. Yet in
+> trying to bring those implementations along as segwit-enforcing software,
+> BIP 148 would risk forking from such clients in the short term! If one
+> really cared about maintaining consensus with older, segwit-enabled
+> software, it would make far more sense to seek segwit activation in a way
+> that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
+> after this one times out). And if one doesn't care about such consensus,
+> then it'd be far simpler to just set (e.g.) August 1 as the flag day
+> activation of segwit, and not play these contortionist games with block
+> version bits, which carry no useful or intrinsic meaning. Either of these
+> two approaches should have the advantage of reduced fork risk, compared
+> with BIP 148.
+>
+> Of course, everyone is free to run the software of their choosing. I
+> write this to both generally convey my opposition to a careless proposal,
+> which I believe represents a way of thinking that is detrimental to
+> Bitcoin's long run success, and specifically explain why I oppose inclusion
+> of this proposal in the Bitcoin Core implementation [3]. The Bitcoin Core
+> project hasn't been, and shouldn't be, careless in deploying consensus
+> changes. Instead, I think the Bitcoin Core project ought to stand up for
+> the best practices that our community has learned about how to deploy such
+> changes (specifically for minimizing chain-split risk when deploying a soft
+> fork!), and I think we should all avoid adoption or encouragement of
+> practices that would depart from the high standards we are capable of
+> achieving.
+>
+>
+> [1] https://lists.linuxfoundation.org/pipermail/
+> bitcoin-dev/2017-March/013811.html
+> [2] https://github.com/bitcoin/bitcoin/pull/9955
+> [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
+>
+>
+> --Suhas Daftuar
+>
+>
+> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
+> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+>> I do not support the BIP148 UASF for some of the same reasons that I
+>> do support segwit: Bitcoin is valuable in part because it has high
+>> security and stability, segwit was carefully designed to support and
+>> amplify that engineering integrity that people can count on now and
+>> into the future.
+>>
+>> I do not feel the the approach proposed in BIP148 really measures up
+>> to the standard set by segwit itself, or the existing best practices
+>> in protocol development in this community.
+>>
+>> The primary flaw in BIP148 is that by forcing the activation of the
+>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
+>> of disruption.
+>>
+>> Segwit was carefully engineered so that older unmodified miners could
+>> continue operating _completely_ without interruption after segwit
+>> activates.
+>>
+>> Older nodes will not include segwit spends, and so their blocks will
+>> not be invalid even if they do not have segwit support. They can
+>> upgrade to it on their own schedule. The only risk non-participating
+>> miners take after segwit activation is that if someone else mines an
+>> invalid block they would extend it, a risk many miners already
+>> frequently take with spy-mining.
+>>
+>> I do not think it is a horrible proposal: it is better engineered than
+>> many things that many altcoins do, but just not up to our normal
+>> standards. I respect the motivations of the authors of BIP 148. If
+>> your goal is the fastest possible segwit activation then it is very
+>> useful to exploit the >80% of existing nodes that already support the
+>> original version of segwit.
+>>
+>> But the fastest support should not be our goal, as a community-- there
+>> is always some reckless altcoin or centralized system that can support
+>> something faster than we can-- trying to match that would only erode
+>> our distinguishing value in being well engineered and stable.
+>>
+>> "First do no harm." We should use the least disruptive mechanisms
+>> available, and the BIP148 proposal does not meet that test. To hear
+>> some people-- non-developers on reddit and such-- a few even see the
+>> forced orphaning of 148 as a virtue, that it's punitive for
+>> misbehaving miners. I could not not disagree with that perspective any
+>> more strongly.
+>>
+>> Of course, I do not oppose the general concept of a UASF but
+>> _generally_ a soft-fork (of any kind) does not need to risk disruption
+>> of mining, just as segwit's activation does not. UASF are the
+>> original kind of soft-fork and were the only kind of fork practiced by
+>> Satoshi. P2SH was activated based on a date, and all prior ones were
+>> based on times or heights. We introduced miner based activation as
+>> part of a process of making Bitcoin more stable in the common case
+>> where the ecosystem is all in harmony. It's kind of weird to see UASF
+>> portrayed as something new.
+>>
+>> It's important the users not be at the mercy of any one part of the
+>> ecosystem to the extent that we can avoid it-- be it developers,
+>> exchanges, chat forums, or mining hardware makers. Ultimately the
+>> rules of Bitcoin work because they're enforced by the users
+>> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
+>> something people can count on: the rules aren't easy to just change.
+>>
+>> There have been some other UASF proposals that avoid the forced
+>> disruption-- by just defining a new witness bit and allowing
+>> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
+>> think they are vastly superior. They would be slower to deploy, but I
+>> do not think that is a flaw.
+>>
+>> We should have patience. Bitcoin is a system that should last for all
+>> ages and power mankind for a long time-- ten years from now a couple
+>> years of dispute will seem like nothing. But the reputation we earn
+>> for stability and integrity, for being a system of money people can
+>> count on will mean everything.
+>>
+>> If these discussions come up, they'll come up in the form of reminding
+>> people that Bitcoin isn't easily changed at a whim, even when the
+>> whims are obviously good, and how that protects it from being managed
+>> like all the competing systems of money that the world used to use
+>> were managed. :)
+>>
+>> So have patience, don't take short cuts. Segwit is a good improvement
+>> and we should respect it by knowing that it's good enough to wait for,
+>> and for however its activated to be done the best way we know how.
+>> _______________________________________________
+>> 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
+>
+>
+
+
+--
+Steven Pine
+(510) 517-7075
+
+--f403045e39de46f28a0550291394
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">I&#39;m glad some discussion has been moved back here.<div=
+><br></div><div>Correct me if I am wrong, but currently core developers are=
+ arguing over whether or not to allow an optional configuration switch whic=
+h defaults off but signals and enforces BIP148 when used. Who are we protec=
+ting users from, themselves? Are you protecting core? from what? I am somew=
+hat genuinely befuddled by those who can&#39;t even allow a user config swi=
+tch to be set.=C2=A0</div><div><br></div><div>I guess I find it all incredi=
+bly silly, but perhaps I suffer from some basic confusion.</div><div><br></=
+div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
+_quote">On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <spa=
+n dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
+target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrot=
+e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
+eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I also do not support=
+ the BIP 148 UASF, and I&#39;d like to add to the points that Greg has alre=
+ady raised in this thread.<div><br></div><div>BIP 148 would introduce a new=
+ consensus rule that softforks out non-segwit signalling blocks in some tim=
+e period.=C2=A0 I reject this consensus rule as both arbitrary and needless=
+ly disruptive.=C2=A0 Bitcoin&#39;s primary purpose is to reach consensus on=
+ the state of a shared ledger, and even though I think the Bitcoin network =
+ought to adopt segwit, I don&#39;t think that concern trumps the goal of no=
+t splitting the network.</div><div><br></div><div>Many BIP 148 advocates se=
+em to start with the assumption that segwit already has a lot of support, a=
+nd suggest that BIP 148 does as well.=C2=A0 However I don&#39;t think it&#3=
+9;s fair or correct to separate the activation proposal for segwit from the=
+ rest of the segwit proposal.=C2=A0 The deployment parameters for segwit ar=
+e consensus-critical; assuming that some other deployment has consensus bec=
+ause it would result in the rest of the segwit proposal activating is an un=
+justified leap.</div><div><br></div><div>Even if there were no feasible alt=
+ernate segwit deployment method available to us, I would hesitate to recomm=
+end that the network adopt a potentially consensus-splitting approach, even=
+ though I firmly believe that the ideas behind segwit are fundamentally goo=
+d ones.=C2=A0 But fortunately that is not the situation we are in; we have =
+substantially less disruptive methods available to us to activate it, even =
+if the current BIP 9 deployment were to fail -- such as another BIP 9 deplo=
+yment in the future, or perhaps a BIP 149 deployment.</div><div><br></div><=
+div>If we do pursue a &quot;user-activated&quot; deployment of segwit, I&#3=
+9;d recommend that we do so in a more careful way than BIP 148 or 149 curre=
+ntly suggest, which as I understand would otherwise make very few changes t=
+o the current implementation.=C2=A0 However, due to the BIP 9 activation as=
+sumption, the Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lu=
+mps together the idea that miners would both enforce the rules and mine seg=
+wit blocks.=C2=A0 However, we can separate these concerns, as we started to=
+ do in the Bitcoin Core 0.14.1 release, where mining segwit blocks is not r=
+equired in order to generally mine or signal for segwit in the software.=C2=
+=A0 And we can go further still: without too much work, we could make furth=
+er improvements to accommodate miners who, for whatever reason, don&#39;t w=
+ant to upgrade their systems, such as by improving block relay from pre-seg=
+wit peers [1], or optimizing transaction selection for miners who are willi=
+ng to enforce the segwit rules but haven&#39;t upgraded their systems to mi=
+ne segwit blocks [2].</div><div><br></div><div>If we would seek to activate=
+ a soft-fork with less clear miner signaling (such as BIP 149), then I thin=
+k such improvements are warranted to minimize network disruption.=C2=A0 In =
+general, we should not seek to censor hashpower on the network unless we ha=
+ve a very important reason for doing so.=C2=A0 While the issues here are nu=
+anced, if I were to evaluate the BIP 148 soft-fork proposal on the spectrum=
+ of &quot;censorship attack on Bitcoin&quot; to &quot;benign protocol upgra=
+de&quot;, BIP 148 strikes me as closer to the former than the latter.=C2=A0=
+ There is simply no need here to orphan these non-signalling blocks that co=
+uld otherwise be used to secure the network.</div><div><br></div><div>To go=
+ further: I think BIP 148 is ill-conceived even for achieving its own presu=
+med goals -- the motivation for adding a consensus rule that applies to the=
+ version bits on blocks is surely for the effect such bits have on older so=
+ftware, such as Bitcoin Core releases 0.13.1 and later.=C2=A0 Yet in trying=
+ to bring those implementations along as segwit-enforcing software, BIP 148=
+ would risk forking from such clients in the short term!=C2=A0 If one reall=
+y cared about maintaining consensus with older, segwit-enabled software, it=
+ would make far more sense to seek segwit activation in a way that didn&#39=
+;t fork from them (such as BIP 149, or a new BIP 9 deployment after this on=
+e times out).=C2=A0 And if one doesn&#39;t care about such consensus, then =
+it&#39;d be far simpler to just set (e.g.) August 1 as the flag day activat=
+ion of segwit, and not play these contortionist games with block version bi=
+ts, which carry no useful or intrinsic meaning.=C2=A0 Either of these two a=
+pproaches should have the advantage of reduced fork risk, compared with BIP=
+ 148.</div><div><br></div><div>Of course, everyone is free to run the softw=
+are of their choosing.=C2=A0 I write this to both generally convey my oppos=
+ition to a careless proposal, which I believe represents a way of thinking =
+that is detrimental to Bitcoin&#39;s long run success, and specifically exp=
+lain why I oppose inclusion of this proposal in the Bitcoin Core implementa=
+tion [3].=C2=A0 The Bitcoin Core project hasn&#39;t been, and shouldn&#39;t=
+ be, careless in deploying consensus changes.=C2=A0 Instead, I think the Bi=
+tcoin Core project ought to stand up for the best practices that our commun=
+ity has learned about how to deploy such changes (specifically for minimizi=
+ng chain-split risk when deploying a soft fork!), and I think we should all=
+ avoid adoption or encouragement of practices that would depart from the hi=
+gh standards we are capable of achieving.</div><div><br></div><div><br></di=
+v><div>=C2=A0[1]=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermai=
+l/bitcoin-dev/2017-March/013811.html" target=3D"_blank">https://lists.<wbr>=
+linuxfoundation.org/pipermail/<wbr>bitcoin-dev/2017-March/013811.<wbr>html<=
+/a><br></div><div>=C2=A0[2]=C2=A0<a href=3D"https://github.com/bitcoin/bitc=
+oin/pull/9955" target=3D"_blank">https://github.com/<wbr>bitcoin/bitcoin/pu=
+ll/9955</a></div><div>=C2=A0[3]=C2=A0<a href=3D"https://github.com/bitcoin/=
+bitcoin/pull/10428#issuecomment-303098925" target=3D"_blank">https://github=
+.com/<wbr>bitcoin/bitcoin/pull/10428#<wbr>issuecomment-303098925</a></div><=
+div><br></div><div><br></div><div>--Suhas Daftuar<br></div><div><div class=
+=3D"h5"><div><br></div><div><br></div><div>On Fri, Apr 14, 2017 at 3:56 AM,=
+ Gregory Maxwell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bi=
+tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
+nuxfounda<wbr>tion.org</a>&gt;</span> wrote:</div><div class=3D"gmail_extra=
+"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
+gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
+ex">I do not support the BIP148 UASF for some of the same reasons that I<br=
+>
+do support segwit:=C2=A0 Bitcoin is valuable in part because it has high<br=
+>
+security and stability, segwit was carefully designed to support and<br>
+amplify that engineering integrity that people can count on now and<br>
+into the future.<br>
+<br>
+I do not feel the the approach proposed in BIP148 really measures up<br>
+to the standard set by segwit itself, or the existing best practices<br>
+in protocol development in this community.<br>
+<br>
+The primary flaw in BIP148 is that by forcing the activation of the<br>
+existing (non-UASF segwit) nodes it almost guarantees at a minor level<br>
+of disruption.<br>
+<br>
+Segwit was carefully engineered so that older unmodified miners could<br>
+continue operating _completely_ without interruption after segwit<br>
+activates.<br>
+<br>
+Older nodes will not include segwit spends, and so their blocks will<br>
+not be invalid even if they do not have segwit support. They can<br>
+upgrade to it on their own schedule. The only risk non-participating<br>
+miners take after segwit activation is that if someone else mines an<br>
+invalid block they would extend it, a risk many miners already<br>
+frequently take with spy-mining.<br>
+<br>
+I do not think it is a horrible proposal: it is better engineered than<br>
+many things that many altcoins do, but just not up to our normal<br>
+standards. I respect the motivations of the authors of BIP 148.=C2=A0 If<br=
+>
+your goal is the fastest possible segwit activation then it is very<br>
+useful to exploit the &gt;80% of existing nodes that already support the<br=
+>
+original version of segwit.<br>
+<br>
+But the fastest support should not be our goal, as a community-- there<br>
+is always some reckless altcoin or centralized system that can support<br>
+something faster than we can-- trying to match that would only erode<br>
+our distinguishing value in being well engineered and stable.<br>
+<br>
+&quot;First do no harm.&quot; We should use the least disruptive mechanisms=
+<br>
+available, and the BIP148 proposal does not meet that test.=C2=A0 To hear<b=
+r>
+some people-- non-developers on reddit and such-- a few even see the<br>
+forced orphaning of 148 as a virtue, that it&#39;s punitive for<br>
+misbehaving miners. I could not not disagree with that perspective any<br>
+more strongly.<br>
+<br>
+Of course, I do not oppose the general concept of a UASF but<br>
+_generally_ a soft-fork (of any kind) does not need to risk disruption<br>
+of mining, just as segwit&#39;s activation does not.=C2=A0 UASF are the<br>
+original kind of soft-fork and were the only kind of fork practiced by<br>
+Satoshi. P2SH was activated based on a date, and all prior ones were<br>
+based on times or heights.=C2=A0 We introduced miner based activation as<br=
+>
+part of a process of making Bitcoin more stable in the common case<br>
+where the ecosystem is all in harmony.=C2=A0 It&#39;s kind of weird to see =
+UASF<br>
+portrayed as something new.<br>
+<br>
+It&#39;s important the users not be at the mercy of any one part of the<br>
+ecosystem to the extent that we can avoid it-- be it developers,<br>
+exchanges, chat forums, or mining hardware makers.=C2=A0 Ultimately the<br>
+rules of Bitcoin work because they&#39;re enforced by the users<br>
+collectively-- that is what makes Bitcoin Bitcoin, it&#39;s what makes it<b=
+r>
+something people can count on: the rules aren&#39;t easy to just change.<br=
+>
+<br>
+There have been some other UASF proposals that avoid the forced<br>
+disruption-- by just defining a new witness bit and allowing<br>
+non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I<br>
+think they are vastly superior. They would be slower to deploy, but I<br>
+do not think that is a flaw.<br>
+<br>
+We should have patience. Bitcoin is a system that should last for all<br>
+ages and power mankind for a long time-- ten years from now a couple<br>
+years of dispute will seem like nothing. But the reputation we earn<br>
+for stability and integrity, for being a system of money people can<br>
+count on will mean everything.<br>
+<br>
+If these discussions come up, they&#39;ll come up in the form of reminding<=
+br>
+people that Bitcoin isn&#39;t easily changed at a whim, even when the<br>
+whims are obviously good, and how that protects it from being managed<br>
+like all the competing systems of money that the world used to use<br>
+were managed. :)<br>
+<br>
+So have patience, don&#39;t take short cuts.=C2=A0 Segwit is a good improve=
+ment<br>
+and we should respect it by knowing that it&#39;s good enough to wait for,<=
+br>
+and for however its activated to be done the best way we know how.<br>
+______________________________<wbr>_________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
+/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
+</blockquote></div><br></div></div></div></div>
+<br>______________________________<wbr>_________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
+<wbr>linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
+/mailman/listinfo/bitcoin-<wbr>dev</a><br>
+<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
+ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
+<div>Steven Pine<div>(510) 517-7075</div></div></div></div>
+</div>
+
+--f403045e39de46f28a0550291394--
+