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