To: bitcoin-dev@lists.linuxfoundation.org
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
	<35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com>
	<f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info>
	<9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com>
	<CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com>
	<9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com>
	<CABaSBayb-FAt0XOX9u+T3-Z2gJQAV-Y7xZS_k6YG74VhPqejQA@mail.gmail.com>
From: Tom Harding <tomh@thinlink.com>
Message-ID: <f10ed0f1-73ee-a6fb-dddf-7a9234fe5c5b@thinlink.com>
Date: Sun, 26 Mar 2017 14:42:51 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABaSBayb-FAt0XOX9u+T3-Z2gJQAV-Y7xZS_k6YG74VhPqejQA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------5BF56F33F4CF6D1E14E7267E"
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
Precedence: list

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

On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     With a tightening of the rule set, a hash power minority that has
>     not upgraded will not produce a minority branch; instead they will
>     simply have any invalid blocks they produce orphaned, serving as a
>     wake-up call to upgrade.
>
>
> False. With bip9-based soft-fork-based activation of segwit, miner
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told miners
> otherwise, let me know.
>

A reasonable miner automatically checks every transaction seen, to see
if it might be valid with his own outputs substituted.


--------------5BF56F33F4CF6D1E14E7267E
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 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote:<br>
    <blockquote
cite="mid:CABaSBayb-FAt0XOX9u+T3-Z2gJQAV-Y7xZS_k6YG74VhPqejQA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Sun, Mar 26, 2017 at 2:05 PM,
            Peter R via bitcoin-dev <span dir="ltr">&lt;<a
                moz-do-not-send="true"
                href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div style="word-wrap:break-word">
                <div>
                  <div>
                    <div>With a tightening of the rule set, a hash power
                      minority that has not upgraded will not produce a
                      minority branch; instead they will simply have any
                      invalid blocks they produce orphaned, serving as a
                      wake-up call to upgrade.</div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>False. With bip9-based soft-fork-based activation of
              segwit, miner blocks will not be orphaned unless they are
              intentionally segwit-invalid (which they currently are
              not). If you have told miners otherwise, let me know.</div>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    A reasonable miner automatically checks every transaction seen, to
    see if it might be valid with his own outputs substituted.<br>
    <br>
  </body>
</html>

--------------5BF56F33F4CF6D1E14E7267E--