To: bitcoin-dev@lists.linuxfoundation.org
References: <CAPg+sBjJcqeqGLHnPyWt23z3YoCRGozQupuMxy51J_-hdkKBSA@mail.gmail.com>
	<E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im>
From: Chris <ctpacia@gmail.com>
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: <E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im>
Content-Type: multipart/alternative;
	boundary="------------080301090108010004070405"
Subject: Re: [bitcoin-dev] On the security of softforks
Precedence: list

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 
<bitcoin-dev@lists.linuxfoundation.org 
<mailto: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
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev &lt;<a
      moz-do-not-send="true"
      href="mailto:bitcoin-dev@lists.linuxfoundation.org"><a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></a>&gt;
    wrote:
    <blockquote cite="mid:E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im"
      type="cite">
      <div>
        <meta http-equiv="content-type" content="text/html;
          charset=windows-1252">
        <span style="color: rgb(34, 34, 34); font-family: 'Helvetica
          Neue', Arial, sans-serif; font-size: 15px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 20px; orphans: auto; text-align: start;
          text-indent: 0px; text-transform: none; white-space: normal;
          widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;
          display: inline !important; float: none;">2) The risk of an
          old full node wallet accepting a transaction whose</span><br
          style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue',
          Arial, sans-serif; font-size: 15px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 20px; orphans: auto; text-align: start;
          text-indent: 0px; text-transform: none; white-space: normal;
          widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
        <span style="color: rgb(34, 34, 34); font-family: 'Helvetica
          Neue', Arial, sans-serif; font-size: 15px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 20px; orphans: auto; text-align: start;
          text-indent: 0px; text-transform: none; white-space: normal;
          widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;
          display: inline !important; float: none;">coins passed through
          a script that depends on the softforked rules.</span></div>
      <br>
    </blockquote>
    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. <br>
    <br>
    This has the effect of dropping non upgraded nodes to a form of spv
    security without their consent. <br>
    <br>
    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. <br>
  </body>
</html>

--------------080301090108010004070405--