public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal
@ 2017-03-31 20:29 praxeology_guy
  2017-03-31 20:57 ` Bram Cohen
  0 siblings, 1 reply; 3+ messages in thread
From: praxeology_guy @ 2017-03-31 20:29 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

TL;DR (In layman terms): Refund any excess fee amounts higher than the lowest included fee in a block.

=== Proposed Hard Fork Change ===

LIFB: Lowest Included Fee/Byte

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

=== Economic Analysis Of Why Such Is Desirable ===

Pure profit seeking miners attempt to fill their block with transactions that have the highest fee/byte. 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. At fill, there is some fee/byte where the next available tx in mempool doesn't get included. 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.

Users who want to create transactions with the lowest fee watch the LIFB with https://bitcoinfees.21.co/ 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.

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

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

Users will look for the money that offers the greatest money transfer efficiency, and tx fees are a big and easily measurable component. So a money system is better if its users can pay lower fees than competing money options. Refund Excees Fee is one way to reduce fees.

=== Technical Difficulties ===

I realize this is a big change... and I'm not sure of the performance problems this might entail... I'm just throwing this idea out there. 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. Also... hard forks are very hard to do in general, so such a hard fork as this might not be worthwhile.

Cheers,
Praxeology Guy

[-- Attachment #2: Type: text/html, Size: 3305 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-31 21:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-31 20:29 [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal praxeology_guy
2017-03-31 20:57 ` Bram Cohen
2017-03-31 21:17   ` praxeology_guy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox