<div>TL;DR (In layman terms): Refund any excess fee amounts higher than the lowest included fee in a block.<br></div><div><br></div><div><div>=== Proposed Hard Fork Change ===<br></div><div><br></div><div>LIFB: Lowest Included Fee/Byte<br></div><div><div><br></div></div><div>Change the fee policy to cause all fee/byte in a block to be reduced to the lowest included fee/byte. Change transactions to specify how/which outputs get what portions of [(TX_fee/TX_length - LIFB)*TX_length].&nbsp; Transactions of course could still offer the remainder to the miner if they don't want to modify some of the outputs and don't want to reveal their change output.<br></div></div><div><br></div><div>=== Economic Analysis Of Why Such Is Desirable ===<br></div><div><br></div><div>Pure profit seeking miners attempt to fill their block with transactions that have the highest fee/byte.&nbsp; So what happens is the users who are willing to offer the highest fee/byte get included first in a block until it gets filled.&nbsp; At fill, there is some  fee/byte where the next available tx in mempool doesn't get included.&nbsp; And right above that fee/byte is the last transaction that was selected to be included in the block, which has the lowest fee/byte of any of the transactions in the block.<br></div><div><br></div><div>Users who want to create transactions with the lowest fee watch the LIFB with <a href="https://bitcoinfees.21.co/">https://bitcoinfees.21.co/</a> or similar systems... so that they can make a transaction that offers a fee at or above the LIFB so that it can be included in a block in reasonable time.<br></div><div><br></div><div>Some users have transactions with very high confirmation time sensitivity/importance... so they offer a fee much higher than the LIFB to guarantee quick confirmation.&nbsp; But they would prefer that even though they are willing to pay a higher fee, that they would still only pay the LIFB fee/byte amount.<br></div><div><br></div><div>This becomes even more of an issue when someone wants to create a transaction now that they want to be included in a block at a much later time... because it becomes harder and harder to predict what the LIFB will be as you try to predict further into the future.&nbsp; It would be nice to be able to specify a very high fee/byte in such a transaction, and then when the transaction is confirmed only have to pay the LIFB.<br></div><div><br></div><div>Users will look for the money that offers the greatest money transfer efficiency, and tx fees are a big and easily measurable component.&nbsp; So a money system is better if its users can pay lower fees than competing money options.&nbsp; Refund Excees Fee is one way to reduce fees.<br></div><div><br></div><div>=== Technical Difficulties ===<br></div><div><br></div><div>I realize this is a big change... and I'm not sure of the performance problems this might entail...&nbsp; I'm just throwing this idea out there.&nbsp; Of course if fees are very small, and there is little difference between a high priority fee/byte and the LIFB, then this issue is not really that big of a deal.&nbsp; Also... hard forks are very hard to do in general, so such a hard fork as this might not be worthwhile.<br></div><div><br></div><div>Cheers,<br></div><div>Praxeology Guy<br></div>