path: root/5e/1c2a68a2ae6408a886a1ac0b3aadbfbde1e1b7

Return-Path: <achow101@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B20B3416
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Oct 2016 15:27:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
	[209.85.220.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6522C1B9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Oct 2016 15:27:34 +0000 (UTC)
Received: by mail-qk0-f174.google.com with SMTP id z190so90074768qkc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Oct 2016 08:27:34 -0700 (PDT)
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; bh=IpE0wwnHJHX5OCA17YNYWqmj+J44vMVrFvLLYNsgnLI=;
	b=X+ZjiF12OTg3WcxLTc8qEIAoXl4kC7zU8IUOWnm4bkjzWVyfC7EUHrdXqYI5babqdl
	iv4LsP+YuSqC9PdI0xA5ZlxY9mtGkSY8GOgd80c3EhA/lVGmXLLpCjnTX45cgpe5qbwK
	1pHlYd1P8FzLx1uhjaHKvnmMeZzxyVtCwEroj5TGLgxQ8GKq7C4KyowAC4Xy7W8dwus8
	lPsAe4cqkkj5r7fGYXaBsSldDW3b4APM8sPQ3IP6Gks3d9kr6zZRqonmkSZTaVB4MWD+
	26DERUsTwuqDHHuMPt1G7qV64RGk58XiAnlTd8tmoIYXGL+UGDQCisgWreqf+c6NhCcM
	cD5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to;
	bh=IpE0wwnHJHX5OCA17YNYWqmj+J44vMVrFvLLYNsgnLI=;
	b=kLDQKZu1/mjII+8cMvBsJCLR/3D3rR+7g2DfiUotQoTcTb9Z56qPpAT6+zuyQOWVDt
	5T80KagCcgo5qc9G8uyQMkyEZR2wPfAJf2R384X1y1hxydzbifKbn1hBtVnpK9k5ddIB
	hmE/HQZ1TpqwKLBgm5Qxjx3og1vpWQ0vEsFOw8KOMY0MJ1xgtZzvbHooGYJH08/Mn2qo
	w8Wtl1xQdVkq2JGu/cb6LWlhu1l5tFCLDALMbDjz1y/pEkrfPaMPoGtt82770pH93QAU
	cIz9GBGxD9kvsKVunkSejf5e0TommEgIJ9bZEeqxW/ceiAgfxD7ZdbqWoO0yRYAySlpl
	0mnw==
X-Gm-Message-State: ABUngvd1I/g5KgMaau+GGD0FD74iHPAbpzXs3Rzco4CUGKZHDJDIi4ajdit2jzhNPVej7Q==
X-Received: by 10.55.104.208 with SMTP id d199mr11401164qkc.222.1477668453476; 
	Fri, 28 Oct 2016 08:27:33 -0700 (PDT)
Received: from [10.108.208.39] ([206.196.187.145])
	by smtp.gmail.com with ESMTPSA id u44sm6486616qtu.5.2016.10.28.08.27.33
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Oct 2016 08:27:33 -0700 (PDT)
To: Andrew <onelineproof@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com>
From: Andrew C <achow101@gmail.com>
Message-ID: <7991eb2d-015c-cedc-518c-988821a2d03f@gmail.com>
Date: Fri, 28 Oct 2016 11:28:35 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
	Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------5E675C7DBE61E88FFA7CF6F5"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] The Soft Fork Deception
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 15:27:35 -0000

This is a multi-part message in MIME format.
--------------5E675C7DBE61E88FFA7CF6F5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On 10/27/2016 11:38 AM, Andrew via bitcoin-dev wrote:
> I have been reading recently through the history of soft forks
> provided by Bitcoin Core:
> https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-re=
cord-of-blockchain-soft-forks.
>
> It has led me to think that there is a deceiving notion that soft
> forks do not force Bitcoin users to upgrade software. Yes, it's true
> that the past soft forks still allow old nodes to accept blocks under
> the tighter rules as valid, but what about miners who are still using
> old software? What about users who want to make a transaction using
> the old rules? Those people are no longer able to do those things. And
> if they want to do those things, a hard fork will result.
A soft fork means that a transaction using the old rules will still
work. Look at segwit, you can still make the original style of
transactions with P2PK, P2PKH, and P2SH outputs. There is nothing here
to cause a hard fork.

> Remember what happened when BIP 66 was activated? Luckily, it was
> short lived, but this is just the beginning. If you keep tightening
> the rules, you are building up more and more pressure for a split in
> the network to occur. You can call this split a "hard fork" or just a
> "fork", but it is dangerous either way, and it leads to basically the
> creation of two coins when before we just had one, people instantly
> lose value, and the trust in Bitcoin's store of value dies.
BIP 66's hard fork was not due to the soft fork making transactions
invalid. Rather it was because miners were not properly validating
blocks before building on top of them. That fork was because a
non-upgraded miner created a block invalid under the new rules and
upgraded miners did not check the block and built on top of it. That
invalid block was only invalid because the isSuperMajority mechanism
specified that the new version number must be used otherwise the block
was invalid, and that was what happened: the invalid block had the old
version number. This is not an issue for BIP 9 Versionbits soft forks
because no such rule exists.
>
> Obviously every one can debate about what should be the definition of
> a soft fork, but whatever that is, I think it is unacceptable how
> sloppily the past soft forks have been deployed.
In what way have these forks been sloppily deployed? The fork caused by
previous a soft forks (there was only one that caused that had an actual
chain split issue) was due to the isSuperMajority mechanism which is not
a good mechanism for deployment. It has been superseded by BIP 9
Versionbits. Furthermore, that fork was not due to "sloppy deployment"
by the devs but rather due to greedy miners who were SPV mining.
> I can think of many ways in which we could have these new features
> that the soft forks provided, but without forcing the new rules, and
> simply making them features that can be used on an individual miner or
> transaction signer basis. Is there a document from Bitcoin Core that
> outlines the philosophy of soft forks and why it is acceptable to
> force the tightening of rules and cause such risks? And please give me
> another reason other than "it removes a few if statements from the code=
".
Can you explain what other risks you think there are with soft forks?
>
> Now that Segregated witness is scheduled to be deployed on November
> 15, we should take a look at this "soft fork" as well. I like the idea
> of Segregated Witness, but from conversations on Reddit and IRC, I see
> people saying that this soft fork will be like the others: requiring a
> hard fork in order to revert it. Is this true?
If you are reading r/btc, you are doing something wrong.

Like with all soft forks, the only way to revert them is by a hard fork.
Soft forks make previously valid things invalid, hard forks make
previously invalid things valid. In order to revert a soft fork which
made something invalid, you need to hard fork to make it valid again.
> I am getting conflicting messages by reading the BIP. It says that if
> all transactions are non-segwit, then a node will validate the block
> as before. But if we pass the threshhold (usually 95 % for 1000
> blocks) will miners mining non-segwit blocks be ignored? This is not
> good... I really think we should make it optional. Miners will have an
> incentive to mine segwit blocks, since it allows for more transactions
> per block, so why force them?
No. This is incorrect. There is no requirement to include the witness
commitment in the coinbase if no transactions in the block contain
witnesses. Because transactions that contain witnesses are considered
non-standard transactions by the old rules, if a miner who did not
upgrade continues to follow those standardness rules, their blocks will
not be invalid and they are not forced to upgrade.
> What if we want to slightly modify the Segwit protocol in the future?
> What if we want to replace segwit with something much different? We
> will be forced to do a hard fork in order to do that.
Not necessarily, it depends on the change. Most changes (such as
sighashing, new opcodes, different scripts, etc.) can be done via
another soft fork because segwit introduces script versioning. A new
script version would be created with the necessary changes and that can
be soft forked in.
>
> Now, we can't go back in time and fix the deployment of the soft
> forks, but I do propose one clean way to fix things: Remove all the
> previously "soft forked" rules for non segwit transactions, and
> require them only for segwit transactions. But make segwit optional!
> In addition to what I talked about above, this may also relieve some
> tensions of people who are not comfortable with segwit and are
> thinking of joining a hard fork like the Bitcoin Unlimited project.
Segwit already is optional. If you don't want to use segwit, you don't
have to. If you don't want to mine segwit blocks, you don't have to.

As for removing all previously soft forked things, then you would be
removing a ton of functionality, various fixes, and potentially break a
large number of transactions that already exists but are not confirmed
yet. This would require a hard fork.

As for what is would be reverted, you would be reverting P2SH (multisig
addresses, you still want those right?), OP_CLTV, OP_CSV, block height
requirement in Coinbase, the value overflow incident, removal of
dangerous opcodes, reduction of block size limit, etc. As you can see, a
lot of functionality and various bug fixes would be lost be reverting
every single soft fork.
>
> Unless people can give me a good explanation as to why we are
> deploying soft forks in such forceful manner,
As I have said throughout this response, soft forks are not deployed in
a forceful manner which forces people to upgrade.
> or Bitcoin Core accepts my proposal, then I will have no choice but to
> create a new client (I'm thinking to call it Bitcoin Authentic), that
> will be just as Bitcoin Core but will always follow the chain with the
> most work regardless of whether soft fork rules are respected, and I
> would put at least CHECKLOCKTIMEVERIFY as mandatory within segwit
> transactions.
Great, go ahead. Honestly, I don't think anyone cares about your
"ultimatum". You are a random person on the internet.
>
> --=20
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------5E675C7DBE61E88FFA7CF6F5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 10/27/2016 11:38 AM, Andrew via
      bitcoin-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>I have been reading recently through the history of soft
            forks provided by Bitcoin Core: <a moz-do-not-send="true"
href="https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks">https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks</a>.<br>
            <br>
          </div>
          It has led me to think that there is a deceiving notion that
          soft forks do not force Bitcoin users to upgrade software.
          Yes, it's true that the past soft forks still allow old nodes
          to accept blocks under the tighter rules as valid, but what
          about miners who are still using old software? What about
          users who want to make a transaction using the old rules?
          Those people are no longer able to do those things. And if
          they want to do those things, a hard fork will result.<br>
        </div>
      </div>
    </blockquote>
    A soft fork means that a transaction using the old rules will still
    work. Look at segwit, you can still make the original style of
    transactions with P2PK, P2PKH, and P2SH outputs. There is nothing
    here to cause a hard fork.<br>
    <br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Remember what happened when BIP 66 was activated? Luckily,
          it was short lived, but this is just the beginning. If you
          keep tightening the rules, you are building up more and more
          pressure for a split in the network to occur. You can call
          this split a "hard fork" or just a "fork", but it is dangerous
          either way, and it leads to basically the creation of two
          coins when before we just had one, people instantly lose
          value, and the trust in Bitcoin's store of value dies.<br>
        </div>
      </div>
    </blockquote>
    BIP 66's hard fork was not due to the soft fork making transactions
    invalid. Rather it was because miners were not properly validating
    blocks before building on top of them. That fork was because a
    non-upgraded miner created a block invalid under the new rules and
    upgraded miners did not check the block and built on top of it. That
    invalid block was only invalid because the isSuperMajority mechanism
    specified that the new version number must be used otherwise the
    block was invalid, and that was what happened: the invalid block had
    the old version number. This is not an issue for BIP 9 Versionbits
    soft forks because no such rule exists.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        Obviously every one can debate about what should be the
        definition of a soft fork, but whatever that is, I think it is
        unacceptable how sloppily the past soft forks have been
        deployed. </div>
    </blockquote>
    In what way have these forks been sloppily deployed? The fork caused
    by previous a soft forks (there was only one that caused that had an
    actual chain split issue) was due to the isSuperMajority mechanism
    which is not a good mechanism for deployment. It has been superseded
    by BIP 9 Versionbits. Furthermore, that fork was not due to "sloppy
    deployment" by the devs but rather due to greedy miners who were SPV
    mining.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">I can think of many ways in which we could have
        these new features that the soft forks provided, but without
        forcing the new rules, and simply making them features that can
        be used on an individual miner or transaction signer basis. Is
        there a document from Bitcoin Core that outlines the philosophy
        of soft forks and why it is acceptable to force the tightening
        of rules and cause such risks? And please give me another reason
        other than "it removes a few if statements from the code".<br>
      </div>
    </blockquote>
    Can you explain what other risks you think there are with soft
    forks?<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div><br>
                </div>
                <div>Now that Segregated witness is scheduled to be
                  deployed on November 15, we should take a look at this
                  "soft fork" as well. I like the idea of Segregated
                  Witness, but from conversations on Reddit and IRC, I
                  see people saying that this soft fork will be like the
                  others: requiring a hard fork in order to revert it.
                  Is this true? </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    If you are reading r/btc, you are doing something wrong.<br>
    <br>
    Like with all soft forks, the only way to revert them is by a hard
    fork. Soft forks make previously valid things invalid, hard forks
    make previously invalid things valid. In order to revert a soft fork
    which made something invalid, you need to hard fork to make it valid
    again.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>I am getting conflicting messages by reading the
                  BIP. It says that if all transactions are non-segwit,
                  then a node will validate the block as before. But if
                  we pass the threshhold (usually 95 % for 1000 blocks)
                  will miners mining non-segwit blocks be ignored? This
                  is not good... I really think we should make it
                  optional. Miners will have an incentive to mine segwit
                  blocks, since it allows for more transactions per
                  block, so why force them? </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    No. This is incorrect. There is no requirement to include the
    witness commitment in the coinbase if no transactions in the block
    contain witnesses. Because transactions that contain witnesses are
    considered non-standard transactions by the old rules, if a miner
    who did not upgrade continues to follow those standardness rules,
    their blocks will not be invalid and they are not forced to upgrade.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>What if we want to slightly modify the Segwit
                  protocol in the future? What if we want to replace
                  segwit with something much different? We will be
                  forced to do a hard fork in order to do that.<br>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Not necessarily, it depends on the change. Most changes (such as
    sighashing, new opcodes, different scripts, etc.) can be done via
    another soft fork because segwit introduces script versioning. A new
    script version would be created with the necessary changes and that
    can be soft forked in.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div><br>
                </div>
                <div>Now, we can't go back in time and fix the
                  deployment of the soft forks, but I do propose one
                  clean way to fix things: Remove all the previously
                  "soft forked" rules for non segwit transactions, and
                  require them only for segwit transactions. But make
                  segwit optional! In addition to what I talked about
                  above, this may also relieve some tensions of people
                  who are not comfortable with segwit and are thinking
                  of joining a hard fork like the Bitcoin Unlimited
                  project.<br>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Segwit already is optional. If you don't want to use segwit, you
    don't have to. If you don't want to mine segwit blocks, you don't
    have to.<br>
    <br>
    As for removing all previously soft forked things, then you would be
    removing a ton of functionality, various fixes, and potentially
    break a large number of transactions that already exists but are not
    confirmed yet. This would require a hard fork.<br>
    <br>
    As for what is would be reverted, you would be reverting P2SH
    (multisig addresses, you still want those right?), OP_CLTV, OP_CSV,
    block height requirement in Coinbase, the value overflow incident,
    removal of dangerous opcodes, reduction of block size limit, etc. As
    you can see, a lot of functionality and various bug fixes would be
    lost be reverting every single soft fork.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div><br>
                </div>
                <div>Unless people can give me a good explanation as to
                  why we are deploying soft forks in such forceful
                  manner, </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    As I have said throughout this response, soft forks are not deployed
    in a forceful manner which forces people to upgrade.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>or Bitcoin Core accepts my proposal, then I will
                  have no choice but to create a new client (I'm
                  thinking to call it Bitcoin Authentic), that will be
                  just as Bitcoin Core but will always follow the chain
                  with the most work regardless of whether soft fork
                  rules are respected, and I would put at least
                  CHECKLOCKTIMEVERIFY as mandatory within segwit
                  transactions.<br clear="all">
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Great, go ahead. Honestly, I don't think anyone cares about your
    "ultimatum". You are a random person on the internet.<br>
    <blockquote
cite="mid:CAL8tG=mfRHidipraCbG7m6V18khf_czWbe=zZN7F6=Ksdae8AQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div><br>
                    -- <br>
                    <div class="gmail_signature">PGP: B6AC 822C 451D
                      6304 6A28  49E9 7DB7 011C D53B 5647</div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------5E675C7DBE61E88FFA7CF6F5--