Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 72C841AC1 for ; Tue, 29 Sep 2015 20:31:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f193.google.com (mail-io0-f193.google.com [209.85.223.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 002AD24B for ; Tue, 29 Sep 2015 20:31:43 +0000 (UTC) Received: by iofb144 with SMTP id b144so2210512iof.1 for ; Tue, 29 Sep 2015 13:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=z+Pd6kv1/xtf39Ud9EJs++RGIhKVylftmhcZYANnNAo=; b=wGm43tauEGhkpRiVzbBhCOlvzzHJoqcvcoyip/3vpNLz20DJdQZJeKWK9fIl6faM20 sHgef9TkmFdbkPJJ6UBzhmTSYDYP4q62mWZdzwYI80hjLWMkGPvpO3nWjJu6h6bZlfe5 5npmwpJU9/ix2dwjV6VXEoMWIqT2wQGqy6vSRYxGVacmZRdc7jy7FXWRodOdlSb1Dcli lKaBrPBkB1GWb01q/W7mIDlZrBBYAFHdCl0RTefuiB03Ha6jcTxdI8QCgHdk9zoDXNvL LPED0MB8gvhUU18BrLQGQDEdDYPl01BO2wK4V5BbBL/tUQFPD8COB/yBLbz7XXy8Lq3F YtXw== MIME-Version: 1.0 X-Received: by 10.107.47.219 with SMTP id v88mr848310iov.134.1443558703251; Tue, 29 Sep 2015 13:31:43 -0700 (PDT) Received: by 10.107.19.30 with HTTP; Tue, 29 Sep 2015 13:31:43 -0700 (PDT) Date: Tue, 29 Sep 2015 20:31:43 +0000 Message-ID: From: Gregory Maxwell To: Dave Scotese Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,PLING_QUERY,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 Cc: Bitcoin Dev Subject: [bitcoin-dev] Are 'soft forks' misnamed? [was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!] X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 20:31:44 -0000 On Mon, Sep 28, 2015 at 10:16 PM, Dave Scotese via bitcoin-dev wrote: > Why are they called soft forks when they are really hidden forks? Isn't the > point of a soft fork to prevent old clients from rejecting what they don't > have the code to validate? That seems dangerous. As an aside, this list loses utility if people insist on taking tangential questions to the list in the middle of threads. It's preferable to either split the thread or take the message off list. The naming arose from a series of historical naming-by-comparisons: The bitcoin network has self-arising forks in state when miners concurrently create blocks. These are natural, unavoidable, and self-resolving. If a nodes enforce different and incompatible rules-- for example, some decide to require that the subsidy stay at 25 BTC forever, then a fork may come into existence which is not self resolvable. Thus the term hardfork arose to talk about rule changes which were incompatible with the existing network, would require all users to upgrade, would exclude all non-consenting users from the resulting system, and which have the power to arbitrarily rewrite rules. This is in contrast to "forks" which are boring, natural, and happen every day. Its often possible to make critical fixes and powerful improvements to the Bitcoin consensus rules by using the unavoidable power of miners to filter transactions according to their own rules. New features and fixes can be carved out of existing "do anything" space in the protocol: like carving a statue out of a block of marble. Doing so reduces the incidence of flag days which are costly to coordinate and actively risky for users and avoids forcing constant software churn, which is bad for decentralization. Such changes are a strict narrowing of permissible actions. And as such, so long as they have a super-majority hashpower behind them any network forking that happens to result from them is automatically self-resolving. So by contrast with hardfork the term softfork came into use to describe these _compatible_ protocol rule changes. There is explicit support for compatible rule changes the bitcoin protocol in the form of no-op opcodes and free form, non-enforced, version fields (for example). Every fix or enhancement you've heard about to Bitcoin's consensus rules (going back to the system's original author) was performed via some form of this mechanism. In the modern form, the behavior to be soft-forked out is first made non-standard (if it wasn't already-- they almost always are) meaning that participants will not relay, mine, or display unconfirmed txn in their wallets transactions which violate the new rule. But if a violation shows up in a block, the block is still accepted. After that the blockchain itself is used to coordinate a vast super-majority of hashpower (recently 95% has been used) agreeing to enforce the new rule which results in confidence confidence of low disruption on account of the enforcement. Then when the threshold is reached, they enforce (automatically). Old software continues to enforce all the old rules they always enforced, the only difference in behavior relates to non-standard transactions and contests between otherwise valid blocks. Even unupgraded participants can tell that the network is doing something new on account of the block version changing (and, for example, Bitcoin Core warns users about this). The primary disadvantage of this approach is that it only allowed you to carve functionality of of "do anything" space, which is quite natural for some features (especially since the Bitcoin protocol includes tons of do anything space)--- e.g. height in coinbase, DER strictness, transactions that have integer overflow creating a kazillion coins-- but less natural for others. Of course, it's always possible for the majority of hashpower to have hidden transaction exclusion rules that _no one_ but them knows about and this cannot be prevented, but at least the mechanism proscribed in modern soft-forks is transparent (the network tells you that its doing something you don't understand).