* [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
* Re: [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal
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
0 siblings, 1 reply; 3+ messages in thread
From: Bram Cohen @ 2017-03-31 20:57 UTC (permalink / raw)
To: praxeology_guy, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
On Fri, Mar 31, 2017 at 1:29 PM, praxeology_guy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>
That would have the unfortunate effect of incentivizing miners to not
completely fill blocks, because low fee marginal transactions could cost
them money.
An alternate approach would be to incentivize miners to follow transaction
fees more by reducing mining rewards, which could be done by soft forking
in a requirement that a chunk of all mining rewards be sent to an
unspendable address.
[-- Attachment #2: Type: text/html, Size: 1298 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal
2017-03-31 20:57 ` Bram Cohen
@ 2017-03-31 21:17 ` praxeology_guy
0 siblings, 0 replies; 3+ messages in thread
From: praxeology_guy @ 2017-03-31 21:17 UTC (permalink / raw)
To: Bram Cohen; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
> That would have the unfortunate effect of incentivizing miners to not completely fill blocks, because low fee marginal transactions could cost them money.
Look at the fee distribution. The vast majority of fee income comes from txs w/ fees near the LIFB. The blocks will be full... but I guess this would make Child Pays For Parent undesirable. CPFP would need a flag saying it is CPFP so that the parent fee isn't considered the LIFB.
[-- Attachment #2: Type: text/html, Size: 514 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