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 85892412 for ; Mon, 6 Mar 2017 23:31:41 +0000 (UTC) X-Greylist: delayed 00:07:34 by SQLgrey-1.7.6 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A6F2012F for ; Mon, 6 Mar 2017 23:31:40 +0000 (UTC) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id D7B7120B45 for ; Tue, 7 Mar 2017 00:24:04 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3vcbTF50qzzyp0; Tue, 7 Mar 2017 00:24:00 +0100 (CET) User-Agent: K-9 Mail for Android In-Reply-To: References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Gareth Williams Date: Tue, 07 Mar 2017 10:23:47 +1100 To: Edmund Edgar , Bitcoin Protocol Discussion Message-ID: <964E4801-234F-4E30-A040-2C63274D27F2@posteo.net> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 07 Mar 2017 00:32:52 +0000 Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation 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: Mon, 06 Mar 2017 23:31:41 -0000 What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with. It is always possible for a majority of hashpower to censor transactions they disagree with. Users may view that as an attack, and can always respond with a POW hard fork. Bitcoin only works if the majority of hashpower is not hostile to the users. On 6 March 2017 9:29:35 PM AEDT, Edmund Edgar via bitcoin-dev wrote: >On 6 March 2017 at 18:18, David Vorick via bitcoin-dev > wrote: >> User activated soft forks, or perhaps more accurately called >'economically >> forced soft forks' are a tool to use if the miners are in clear >opposition >> to the broader economy. > >I don't think they work for that, at least not for new features, >because miners will presumably just head the whole thing off by >orphaning the whole class of non-standard transactions that are the >subject of the fork. In the SegWit case, they'd just orphan anything >that looks like a SegWit transaction, valid or not. That way they >don't need to worry about ending up on the wrong side of the upgrade, >because no transaction affected by the proposed rule change will ever >get into the longest chain. Rational node operators (particularly >exchanges) will likely also adopt their stricter rule change, since >they know any chain that breaks it will end up being orphaned, so you >don't want to act on a payment that you see confirmed in it. So then >you're back where you started, except that your soft-fork is now a >de-facto hard-fork, because you have to undo the new, stricter rule >that the miners introduced to head off your shenannigans. > >Where they're interesting is where you can do something meaningful by >forcing some transactions through on a once-off basis. For example, if >the Chinese government identified an address belonging to Uighur >separatists and leaned on Chinese miners to prevent anything from that >address confirming, it might be interesting for users to say, "If >these utxos are not spent by block X, your block is invalid". > >They might also be interesting for feature upgrades in a world where >mining is radically decentralized and upgrades are fighting against >inertia rather than opposition, but sadly that's not the world we >currently live in.