path: root/e3/a55e7553539fc7ecb96ef1cce0f54b1b638ff8

Return-Path: <da2ce7@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6F9ABB63
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 06:28:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
	[209.85.215.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 91755F0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 06:28:45 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id 75so48455505lfs.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Apr 2017 23:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=+neN3CZJwko+bMWtBHsbJaIjUK8IRus/pm/nGBe0/Ns=;
	b=pN5q0vaxjmmVfgODDbaf48vzmch2KkkWTjsPYm8+E6rg9E71Lr41imG6i7kgut6xCA
	mbjfGFEzKejrQDMlErtJafVLvLrZQKp6XlEGzA5+j2904mResnL76mAZd6aXRDerGrGW
	W7tqweBU3+4kzvchHzFMBUESUJ6IHfXDvFl5AJimlHyr7zV4W6eOGJdH4RuNi7fqh6Oe
	7m0NgItfKGxp005aBvRWmuloYEc+njGUP0NGjkmp5fh37sBSC0V/J+kCt6egyDKmkw9C
	2q5Uwia/RRnFQgKCRiBwQvqj5NFYcz04OTbZakZExkBBHtWt7Od0bjSwRV6hohAgMiWJ
	9Ekg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=+neN3CZJwko+bMWtBHsbJaIjUK8IRus/pm/nGBe0/Ns=;
	b=AWJrUcoLTDcbW6iyA1mCKwOPoYNN9pDqShlsBGjCA3NI+bxMR37ci/lzjmqPS/lxss
	LUrh2unaDw/IYHLFe0ofCI9dUAoik1puVDfyMgryRVs3P/LWI2ehooyFX+W/AKcZ7s1O
	Ddb8REWMy5HVAW9kZ8TCuUQKt1hBSkbYmc30BzSdvjhf/7iis/r8vPc8BQbq7V4DjWnV
	nGYUlp3Yi4ntTSHGaDrwOmi/cVyVoZfSeW9s+bErqSE02NEddkoU6B745KdYOpK7UgXM
	/nTe9Zc8oYDyIbasO9nokv73ylc5twK65SJTq4wvlPUh9NvHiBuzGqKW9v4tAleyJTUe
	slyg==
X-Gm-Message-State: AN3rC/7ko2x008SnWcDaa78c7RuKQigaHJxkLwng+kj1iQHBIOMwXo9x
	wVYQ1cPjj3DYDg==
X-Received: by 10.25.165.7 with SMTP id o7mr373504lfe.141.1492237723831;
	Fri, 14 Apr 2017 23:28:43 -0700 (PDT)
Received: from [192.168.0.102] ([78.26.162.42])
	by smtp.gmail.com with ESMTPSA id 11sm764684ljv.67.2017.04.14.23.28.42
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 14 Apr 2017 23:28:42 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Cameron Garnham <da2ce7@gmail.com>
In-Reply-To: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
Date: Sat, 15 Apr 2017 09:28:41 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7A3E345-15C9-4C4C-B3D7-C75634243430@gmail.com>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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: Sat, 15 Apr 2017 06:28:46 -0000

Hello,

It is hard for me to come out disagreeing with Maxwell, however in this =
case I feel I must.

As many may remember, there was quite some controversy about the BIP16 =
vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, =
and how this was the already =E2=80=9Ctested and proven to work=E2=80=9D =
solution.

I was one of the man hold-out supporters of BIP17, not for any clear =
reason (I now have a much better technical understanding of the Bitcoin =
technical details, as we all do); But because it was the =E2=80=98more =
elegant=E2=80=99 solution.  I knew from other fields of engineering that =
elegant solutions very often better deal with the =E2=80=98unknown, =
unknowns=E2=80=99.  I also didn=E2=80=99t agree with Gavin=E2=80=99s =
=E2=80=98the sky is falling=E2=80=99 sense of urgency.

However, of-course the community got behind BIP16, it was activated, =
fortunately, without any signifiant incident.

I did learn that in Bitcoin there is something more valuable than =
technical elegance: that is community buy-in. On the technical side, the =
engineers need to make sure the solutions are viable: however on the =
community side we need to make sure that the good solutions are adopted =
in a reasonable timeframe.

It is both my empirical view and heart-felt belief that the wider =
Bitcoin Community wants SegWit quickly. In this case the sacrifice of =
some technical elegance and correctness for expediency is prudent!

It is my unfortunate view that Maxwell is missing the political forest =
for the technical trees.  Not only is SegWit a technical solution to =
technical problems; it has come to represent, by the larger Bitcoin =
Community, a political solution to the conflict that we are waist-deep =
in every, single, day.

BIP 148 is out terms of peace.  The Bitcoin Community is tired-to-death =
of this war and wants a resolution swiftly. BIP 148 proves a outlet, and =
in Maxwell words: =E2=80=9C...almost guarantees at a minor level of =
disruption.=E2=80=9D.

I am willing to go through this minor level of disruption, as the daily =
disruption from the =E2=80=9Cscaling debate war=E2=80=9D; in my personal =
online life, is far greater.

SegWit is a exceptional feat of engineering, it solves and mitigates so =
many small and highly subtle issues within Bitcoin; yet still managed to =
be simple enough successfully reviewed: now the community is clearly =
calling for a quick activation of the =E2=80=98viable=E2=80=99 technical =
choice.

If you/we are going to provide any engineering solution to activating =
SegWit, then Swiftness should be the 1st priority after viability.

BIP 148 is both Swift and Viable.

Cameron.



> On 14 Apr 2017, at 10:56 AM, Gregory Maxwell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> "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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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. :)
>=20
> 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