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 6BD56B7D for ; Sat, 15 Apr 2017 07:46:50 +0000 (UTC) X-Greylist: delayed 20:54:02 by SQLgrey-1.7.6 Received: from homiemail-a79.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A3B3DF for ; Sat, 15 Apr 2017 07:46:49 +0000 (UTC) Received: from homiemail-a79.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTP id 83CF66002B13 for ; Sat, 15 Apr 2017 00:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=chrisacheson.net; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= chrisacheson.net; bh=3jeVBpW11Es8Fo4kln/7W8TMFyk=; b=EnZnqJwJ4qS AlBBhOCzhM3jtMdkuWYZIVqQx0YTa9vlw6JZL+jayQNtGZQ2oPG1fZIoiLQHwmip e6TtdGrFOckY56/nyehGio/3CaBqkxaz3eTwT1yQrMeAGC9GJ1nqCxygOzPIIAS6 Jem2E6lQ6i21DXDAXPezXmkCCP+VzaYk= 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 0F0D16002B12 for ; Sat, 15 Apr 2017 00:46:48 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Chris Acheson Message-ID: <2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net> Date: Sat, 15 Apr 2017 03:46:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: 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: Sat, 15 Apr 2017 11:51:19 +0000 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 07:46:50 -0000 On 04/15/2017 03:04 AM, Gregory Maxwell via bitcoin-dev wrote: > Considering that you did not spare a single word about the specific > property that I am concerned about-- that the proposal will reject > the blocks of passive participants, due to avoidable design > limitations-- I can't help but feel that you don't even care to > understand the concern I was bringing up. :( Not sure if you missed my previous reply to you, but I'm curious about your thoughts on this particular point. I contend that for any UASF, orphaning non-signalling blocks on the flag date is safer than just considering the fork active on the flag date. Unless we have majority miner support for the fork, we have to assume that a chain split will occur at some point. With the orphaning approach, we know exactly when that will be, and can plan around it. Miners know that they need to upgrade by the flag date in order to get paid. We even have an opportunity to back out if it looks like we don't have enough economic support. With the non-orphaning approach, the split won't occur until someone chooses to craft a malicious block (short bitcoin; rent hash power; profit). We don't know when that will be, so we can't plan around it. Some nodes and miners will assume it won't happen at all. When it happens, our responses to it will be clumsy, uncoordinated, and likely panicked. While the orphaning approach is potentially disruptive to miners, it is necessarily so in order to minimize disruption to users. In general, users should be prioritized over miners. The point of Bitcoin is to have secure, digital money that we can *use*, not to enable people to earn money from running busy-work computations. > How many people barely reviewed the specifics of the proposal simply > because they want something fast and this proposal does something > fast? I have scrutinized the strategy of BIP148 a fair bit. I was initially opposed to it, but after Bitfury showed their support, and especially after the Asicboost revelation, I think it has solid potential to succeed. It would be a waste not to at least attempt to organize around it. If it turns out that we can't get the necessary support in time, we can abandon the effort and reassess our options.