<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>As i understand it, the transactions to be included in a block
      are entirely up to the miner of that block.</p>
    <p><br>
    </p>
    <p>What prevents a miner from implementing the proposal on their
      own?</p>
    <p><br>
    </p>
    <p>If this is adopted as some kind of "policy", what forces a miner
      to follow it?<br>
    </p>
    <pre class="moz-signature" cols="72">Jim Renkel
</pre>
    <div class="moz-cite-prefix">On 12/2/2017 10:07 PM, Damian
      Williamson via bitcoin-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
      <div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;"
        dir="ltr">
        <p style="margin-top:0;margin-bottom:0"># BIP Proposal: UTWFOTIB
          - Use Transaction Weight For Ordering Transactions In Blocks<br>
        </p>
        <br>
        I admit, with my limited experience in the operation of the
        protocol, the section entitled 'Solution operation' may not be
        entirely correct but you will get the idea. If I have it wrong,
        please correct it back to the list.<br>
        <br>
        <p style="margin-top:0;margin-bottom:0">## The problem:<br>
        </p>
        <br>
        <p style="margin-top:0;margin-bottom:0">Everybody wants value.
          Miners want to maximize revenue from fees. Consumers want
          transaction reliability and, (we presume) low fees.<br>
        </p>
        <br>
        Current transaction bandwidth limit is a limiting factor for
        both.<br>
        <br>
        <p style="margin-top:0;margin-bottom:0">## Solution summary:<br>
        </p>
        <br>
        <p style="margin-top:0;margin-bottom:0">Provide each transaction
          with a transaction weight, being a function of the fee paid
          (on a curve), and the time waiting in the transaction pool
          (also on a curve) out to n days (n=30 ?); the transaction
          weight serving as the likelihood of a transaction being
          included in the current block, and then use a target block
          size.
          <br>
        </p>
        <br>
        Protocol enforcement to prevent high or low blocksize cheating
        to be handled by having the protocol determine the target size
        for the current block using; current transaction pool size x ( 1
        / (144 x n days ) ) = transactions to be included in the current
        block.<br>
        <br>
        The curves used for the weight of transactions would have to be
        appropriate.<br>
        <br>
        <p style="margin-top:0;margin-bottom:0">## Pros:<br>
        </p>
        <br>
        * Maximizes transaction reliability.<br>
        * Maximizes possibility for consumer and business uptake.<br>
        * Maximizes total fees paid per block without reducing
        reliability; because of reliability, confidence and uptake are
        greater; therefore, more transactions and more transactions
        total at priority fees.<br>
        * Market determines fee paid for transaction priority.<br>
        <p style="margin-top:0;margin-bottom:0">* Fee recommendations
          work all the way out to 30 days or greater.<br>
        </p>
        * Provides additional block entropy and greater security since
        there is less probability of predicting the next block.<br>
        <br>
        <p style="margin-top:0;margin-bottom:0">## Cons:<br>
        </p>
        <br>
        * ?<br>
        * Must be first be programmed.<br>
        * Anything else?<br>
        <br>
        <p style="margin-top:0;margin-bottom:0">## Solution operation:<br>
        </p>
        <br>
        <p style="margin-top:0;margin-bottom:0">As I have said, my
          simplistic view of the operation. If I have this wrong, please
          correct it back to the list.<br>
        </p>
        <br>
        1. The protocol determines the target block size.<br>
        <p style="margin-top:0;margin-bottom:0">2. Assign each
          transaction in the pool a transaction weight based on fee and
          time waiting in the transaction pool.<br>
        </p>
        <p style="margin-top:0;margin-bottom:0">3. Begin selecting
          transactions to include in the current block using transaction
          weight as the likelihood of inclusion until target block size
          is met.<br>
        </p>
        4. Solve block.<br>
        <br>
        <p style="margin-top:0;margin-bottom:0">Regards,</p>
        <p style="margin-top:0;margin-bottom:0">Damian Williamson<br>
        </p>
      </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>