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 231FBB63 for ; Fri, 15 Sep 2017 20:15:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.osc.co.cr (unknown [168.235.79.83]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84D947C for ; Fri, 15 Sep 2017 20:15:39 +0000 (UTC) Received: from [192.168.2.225] (miner1 [71.94.45.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: danda) by mail.osc.co.cr (Postfix) with ESMTPSA id A624A3D6A8; Fri, 15 Sep 2017 13:15:38 -0700 (PDT) To: Andrew Quentson , Bitcoin Protocol Discussion References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr> From: Dan Libby Message-ID: Date: Fri, 15 Sep 2017 13:15:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.3 required=5.0 tests=RDNS_NONE autolearn=disabled version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 15 Sep 2017 21:00:22 +0000 Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented? 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, 15 Sep 2017 20:15:40 -0000 Thanks for this link. From my reading though, it seems that only soft-forks that attempt to freeze funds are problematic on ethereum. >From the article: > The soft fork creates a new and fundamentally different class of > transactions in contrast with those that currently exist within the > protocol. Currently, transactions either complete successfully and > cause a state transition, or run into an exception, in which case > state is reverted but the maximum possible gas is still charged. With > the soft fork, transactions which interact with a DAO will not fit > within these two classes: they will fail execution but no gas will be > charged. This must inevitably be the case in any soft fork that aims > to freeze the stolen funds; So in the general case ethereum can still soft-fork I think... On 09/15/2017 04:19 AM, Andrew Quentson wrote: > From my understanding, the blockchain can be designed in such a way as > to make soft-forks be impossible or at least impractical due to attack > vectors. > > http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/ > > Ethereum, for example, can't soft-fork. They have to always hardfork. > > On 13 September 2017 at 10:50, Dan Libby via bitcoin-dev > > wrote: > > Hi, I am interested in the possibility of a cryptocurrency software > (future bitcoin or a future altcoin) that strives to have immutable > consensus rules. > > The goal of such a cryptocurrency would not be to have the latest and > greatest tech, but rather to be a long-term store of value and to offer > investors great certainty and predictability... something that markets > tend to like. And of course, zero consensus rule changes also means > less chance of new bugs and attack surface remains the same, which is > good for security. > > Of course, hard-forks are always possible. But that is a clear split > and something that people must opt into. Each party has to make a > choice, and inertia is on the side of the status quo. Whereas > soft-forks sort of drag people along with them, even those who oppose > the changes and never upgrade. In my view, that is problematic, > especially for a coin with permanent consensus rule immutability as a > goal/ethic. > > As I understand it, bitcoin soft-forks always rely on anyone-can-spend > transactions. If those were removed, would it effectively prevent > soft-forks, or are there other possible mechanisms? How important are > any-one-can spend tx for other uses? > > More generally, do you think it is possible to programmatically > avoid/ban soft-forks, and if so, how would you go about it? > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > -- Dan Libby Open Source Consulting S.A. Santa Ana, Costa Rica http://osc.co.cr phone: 011 506 2204 7018 Fax: 011 506 2223 7359