diff options
author | Steven Pine <steven.pine@gmail.com> | 2017-05-23 00:03:49 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-05-23 04:03:54 +0000 |
commit | 5157da8e16c0b8406a3225719b0d1047ac0b5305 (patch) | |
tree | 7ec2b602a1340d4e8939356b443257817f9315ff | |
parent | 0ba404563fb4fdde32c48d91caaa3e27f95c8968 (diff) | |
download | pi-bitcoindev-5157da8e16c0b8406a3225719b0d1047ac0b5305.tar.gz pi-bitcoindev-5157da8e16c0b8406a3225719b0d1047ac0b5305.zip |
Re: [bitcoin-dev] I do not support the BIP 148 UASF
-rw-r--r-- | 2a/bfaffbe8a2fbde294cb1c77f45b46596323637 | 507 |
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'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'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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = +target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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'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'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 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't think it= +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 "user-activated" deployment of segwit, I= +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'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'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 "censorship attack on Bitcoin" to "benign protocol upgra= +de", 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'= +;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't care about such consensus, then = +it'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'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't been, and shouldn'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"><<a href=3D"mailto:bi= +tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li= +nuxfounda<wbr>tion.org</a>></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 >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> +"First do no harm." 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'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'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's kind of weird to see = +UASF<br> +portrayed as something new.<br> +<br> +It'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're enforced by the users<br> +collectively-- that is what makes Bitcoin Bitcoin, it's what makes it<b= +r> +something people can count on: the rules aren'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'll come up in the form of reminding<= +br> +people that Bitcoin isn'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't take short cuts.=C2=A0 Segwit is a good improve= +ment<br> +and we should respect it by knowing that it'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-- + |