To: bitcoin-dev@lists.linuxfoundation.org
References: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: Jim Renkel <jim.renkel@comcast.net>
Message-ID: <52700305-585d-4239-134e-ac8c5b6c4165@comcast.net>
Date: Tue, 5 Dec 2017 23:18:11 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative;
	boundary="------------C5DAE4AB670F179367B42B7E"
Content-Language: en-US
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
 For Ordering Transactions In Blocks
Precedence: list

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

As i understand it, the transactions to be included in a block are 
entirely up to the miner of that block.


What prevents a miner from implementing the proposal on their own?


If this is adopted as some kind of "policy", what forces a miner to 
follow it?

Jim Renkel

On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:
>
> # BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering 
> Transactions In Blocks
>
>
> 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.
>
> ## The problem:
>
>
> Everybody wants value. Miners want to maximize revenue from fees. 
> Consumers want transaction reliability and, (we presume) low fees.
>
>
> Current transaction bandwidth limit is a limiting factor for both.
>
> ## Solution summary:
>
>
> 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.
>
>
> 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.
>
> The curves used for the weight of transactions would have to be 
> appropriate.
>
> ## Pros:
>
>
> * Maximizes transaction reliability.
> * Maximizes possibility for consumer and business uptake.
> * 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.
> * Market determines fee paid for transaction priority.
>
> * Fee recommendations work all the way out to 30 days or greater.
>
> * Provides additional block entropy and greater security since there 
> is less probability of predicting the next block.
>
> ## Cons:
>
>
> * ?
> * Must be first be programmed.
> * Anything else?
>
> ## Solution operation:
>
>
> As I have said, my simplistic view of the operation. If I have this 
> wrong, please correct it back to the list.
>
>
> 1. The protocol determines the target block size.
>
> 2. Assign each transaction in the pool a transaction weight based on 
> fee and time waiting in the transaction pool.
>
> 3. Begin selecting transactions to include in the current block using 
> transaction weight as the likelihood of inclusion until target block 
> size is met.
>
> 4. Solve block.
>
> Regards,
>
> Damian Williamson
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------C5DAE4AB670F179367B42B7E
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<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>

--------------C5DAE4AB670F179367B42B7E--