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>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Precedence: list

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