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 58C33B49 for ; Fri, 15 Sep 2017 21:49:00 +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 14CE5442 for ; Fri, 15 Sep 2017 21:48:59 +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 DAA0B3D6A8; Fri, 15 Sep 2017 14:48:58 -0700 (PDT) To: Simone Bronzini , Bitcoin Protocol Discussion , ZmnSCPxj References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr> <9a541ba8-7c25-fdbb-505f-6426f61bdc63@osc.co.cr> <0c98e067-dff3-988b-af66-7c624de3eef4@chainside.net> From: Dan Libby Message-ID: <97b3b1a4-f588-65c7-d5cf-e8110ec3e4b5@osc.co.cr> Date: Fri, 15 Sep 2017 14:48:57 -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: <0c98e067-dff3-988b-af66-7c624de3eef4@chainside.net> 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: Sat, 16 Sep 2017 12:19:28 +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 21:49:00 -0000 On 09/15/2017 01:40 PM, Simone Bronzini wrote: > Since a soft-fork is a restriction of the consensus rules, I think the > only way to have an un-soft-forkable cryptocurrency is creating a > cryptocurrency where no transaction is valid. > > Imagine I build a very minimal cryptocurrency where in the transaction > output you only indicate the public key to send your coins to and the > amount. One can still soft-fork it by deciding that, from now on, only > even amounts are valid or only public keys that are a multiple of 10 are > valid. sure, but in this scenario how would one meaningfully "upgrade" the functionality, eg add a new opcode? We couldn't, right? so.... success! Preventing new functionality is the primary goal of this thought experiment. I believe that common sense and market incentives would prevent arbitrary tightening of the rules for no good reason...