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 C5E8EC8B for ; Fri, 14 Apr 2017 22:55:35 +0000 (UTC) X-Greylist: delayed 12:02:46 by SQLgrey-1.7.6 Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DED6107 for ; Fri, 14 Apr 2017 22:55:35 +0000 (UTC) Received: from homiemail-a79.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by hapkido.dreamhost.com (Postfix) with ESMTP id 8F5AC8715C for ; Fri, 14 Apr 2017 03:52:48 -0700 (PDT) Received: from homiemail-a79.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTP id D66226002752 for ; Fri, 14 Apr 2017 03:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=chrisacheson.net; h=to :from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=chrisacheson.net; bh=Jcp3UcPPFazko u4KdgCU86IICGw=; b=GAU/uu13g8aMRxEfBYGVH7ZlfGgOB4mRW5HiOiy53tNkd gfCmhAdE8eDuYcY2CRVJIA6j1VYK60bkVpP95SU5vPYcVNwJvmzm2rwgBMhNB2LH /pcYzPMyQaL/nTUAo81wKHBxxR0mkCtIYqX45B89JIUpMk0w0295QY/1fOtVpE= Received: from [192.168.1.2] (unknown [104.153.30.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@chrisacheson.net) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTPSA id A0790600274A for ; Fri, 14 Apr 2017 03:52:47 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org From: Chris Acheson Message-ID: <03e427ef-c655-7ec6-78a2-717b78bc43af@chrisacheson.net> Date: Fri, 14 Apr 2017 06:52:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 X-Mailman-Approved-At: Fri, 14 Apr 2017 23:04:04 +0000 Subject: [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: Fri, 14 Apr 2017 22:55:35 -0000 Speaking as one of the BIP148 agitators: > 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. I'm assuming that you're referring to the flag date "segwit is on now" approach. This is more dangerous than the orphaning approach that BIP148 uses. If we orphan non-signalling blocks on the flag date and don't have majority hash power supporting us, there will be a chain split on the flag day. We expect this to happen, we plan for it, and we employ strategies to mitigate any damage. The bulk of the economy has coordinated around this event happening. We even had the opportunity to pull the plug before the flag date if things were looking too grim. After the dust settles, 100% of the miners are guaranteed to have upgraded, assuming they didn't choose to forgo 2+ weeks of income. Any further chain splits would have to be the result of deliberate action by 51%+ of the mining power. If we just have segwit activate on the flag date without orphaning the blocks of non-segwit miners, we set ourselves up for a chain split at some unknown time in the future. Without majority hash power on our side, as soon as someone mines a segwit-invalid transaction, the chain will split, with upgraded nodes and miners on one side, and non-upgraded nodes and miners on the other side. The segwit-invalid transaction doesn't even need to come from someone with their own mining equipment. Open a short on BTC, rent some hash power, profit. Since we don't know when this attack will occur, we won't be organized and ready for it. It's also easy for both miners and users to get complacent about it and fail to upgrade. The damage will be far worse than if we had used the orphaning approach. > "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. Punitive action against miners is not the point of BIP148, it's an unavoidable side-effect of making the UASF less disruptive for the users of Bitcoin. Minimizing disruption for users must take priority over minimizing disruption for miners. Given the intensity of this dispute and the bad faith of certain actors, some schadenfreude is bound to occur. Don't let that distract you from the actual reasons that BIP148 is designed the way it is. > 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. I respect this perspective, and I agree with it to a certain extent. However, continuing to wait has costs. I do not believe we have the luxury of continuing to wait for a couple more years. In doing so it's entirely possible that we may damage our reputation for stability and integrity rather than build on it. We have a window of opportunity with BIP148, and it would be a waste not to act on it. In the event that we still lack sufficient support by July, we can abandon the project, and make plans for how best to proceed from there.