path: root/2a/bfaffbe8a2fbde294cb1c77f45b46596323637

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--