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 7C5F4EAF for ; Sat, 19 Dec 2015 01:36:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D4FFCEE for ; Sat, 19 Dec 2015 01:36:23 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id v36so46704502qgd.2 for ; Fri, 18 Dec 2015 17:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=raiBUHV8sMLC/BtrYr1XHPUnbx/XPQXwC/kkUY4mwBc=; b=fJoznNgMwJH61/jPZUCuARx1KauMh+vA4Ard/8uHQ3bPaPb3V740MAIOcTiSd5XRbi 7bDizuQNvpzktv5bpK2b1aBWB4MXyMfPJXyKiCWhrYfgkWO83okCLx1Gy9ddb/G25Idy k+kA4GuHgShiTzqFz7mOV99lCgQLxdu+1LPULW7jIY2Gy9nsogMEpqETEpB5bezklcQs upm8fB4q4xjCZh1tEhY7P4HEWpzmryrBe+iNuYDAokQQdb4SSZ5Dyer+YZEXyvmYDPYT Ou0VkYvxamY+cdAo8rWaWspkebB7lEbCqjEcEMTsYeSMBfMErK7tr0I6tfKjc3evxCTG 34vg== X-Received: by 10.140.144.205 with SMTP id 196mr10008472qhq.38.1450488983051; Fri, 18 Dec 2015 17:36:23 -0800 (PST) Received: from [192.168.1.15] (pool-72-82-165-31.cmdnnj.east.verizon.net. [72.82.165.31]) by smtp.gmail.com with ESMTPSA id f7sm7929230qhf.7.2015.12.18.17.36.22 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 17:36:22 -0800 (PST) To: bitcoin-dev@lists.linuxfoundation.org References: From: Chris Message-ID: <5674B495.10903@gmail.com> Date: Fri, 18 Dec 2015 20:36:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080301090108010004070405" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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: Sat, 19 Dec 2015 08:38:30 +0000 Subject: Re: [bitcoin-dev] On the security of softforks 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: Sat, 19 Dec 2015 01:36:24 -0000 This is a multi-part message in MIME format. --------------080301090108010004070405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev > wrote: > 2) The risk of an old full node wallet accepting a transaction whose > coins passed through a script that depends on the softforked rules. > There's that, but there's also a case where an attacker creates a majority chain that follows the old rules but not the new ones. Non-upgraded nodes would accept a transaction on what they believe to be the consensus chain only to find that when they try to spend those coins no one accepts them because they were part of an invalid chain. This has the effect of dropping non upgraded nodes to a form of spv security without their consent. This is in contrast to a hard fork where a full node operator could explicitly set their node to accept higher version blocks that it can't validate. They get the soft fork functionality back but they have at least consented to it rather than have it forced on them. Doing forks that way would also have the benefit of notifying the user they are accepting unvalidated coins, whereas they wont know that in a soft fork. --------------080301090108010004070405 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
2) The risk of an old full node wallet accepting a transaction whose
coins passed through a script that depends on the softforked rules.

There's that, but there's also a case where an attacker creates a majority chain that follows the old rules but not the new ones. Non-upgraded nodes would accept a transaction on what they believe to be the consensus chain only to find that when they try to spend those coins no one accepts them because they were part of an invalid chain.

This has the effect of dropping non upgraded nodes to a form of spv security without their consent.

This is in contrast to a hard fork where a full node operator could explicitly set their node to accept higher version blocks that it can't validate. They get the soft fork functionality back but they have at least consented to it rather than have it forced on them. Doing forks that way would also have the benefit of notifying the user they are accepting unvalidated coins, whereas they wont know that in a soft fork.
--------------080301090108010004070405--