From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6F9ABB63 for ; 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 ; Sat, 15 Apr 2017 06:28:45 +0000 (UTC) Received: by mail-lf0-f44.google.com with SMTP id 75so48455505lfs.2 for ; 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 In-Reply-To: Date: Sat, 15 Apr 2017 09:28:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Gregory Maxwell 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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