<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 04/21/2014 11:40 AM, Ashley Holman wrote:<br>
    <blockquote
cite="mid:CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Mon, Apr 21, 2014 at 1:36 PM,
            Peter Todd <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span>
            wrote:
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              That is mistaken: you can't mine on top of just a block
              header, leaving small miners disadvantaged as they are
              earning no profit while they wait for the information to
              validate the block and update their UTXO sets. This
              results in the same problem as before, as the large pools
              who mine most blocks can validate either instantly - the
              self-mine case - or more quickly than the smaller miners.<br>
              <br>
            </blockquote>
            <div>&nbsp;</div>
            <div>Under the headers first scenario, wouldn't the full
              block still reach everyone in the same time as it would
              under the current rules? &nbsp;So the small miner loses nothing
              in terms of updating their UTXO set, but gains an early
              "heads up" alert that a new block is coming. &nbsp;This allows
              them spend the propagation time working more productively
              on an empty block in the new chain rather than wasting
              time on an orphan. &nbsp;It's true that it doesn't solve the
              problem of larger pools vs smaller pools, but if it
              doesn't make it any worse then headers-first propagation
              would be a net benefit to the network since it removes the
              incentive to make small blocks.</div>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
    I think the most important part is that nodes can reliably decide on
    "first received", regardless of how they subsequently act on it.&nbsp; I
    believe it would be fine for a node to receive a header and continue
    mining the old block, or a subsequently-verified competing block,
    until it has the necessary pieces to fully verify the first header
    received.&nbsp; If that block data doesn't come, then it will be
    naturally ignored.&nbsp; But if multiple blocks come at once, even if a
    competing block "verifies" first, the node would still switch to
    considering the first header received as the best block when it
    later receives proof it is valid (which may only be a couple
    seconds). <br>
    <br>
    In other words, the node will always consider the header-received
    time as the primary ordering criteria, but will not mine on anything
    until it has full proof of validity, even if <i>that</i> is out of
    order.&nbsp; This means that new blocks "effectively" propagate at the
    speed of 80 bytes, which limits certain kinds of
    block-injection/racing attacks.&nbsp; <br>
    <br>
    <br>
  </body>
</html>