public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: praxeology_guy <praxeology_guy@protonmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal
Date: Fri, 31 Mar 2017 16:29:41 -0400	[thread overview]
Message-ID: <1dvInLVM9fq2GjQVacau8gDyslYCCx_6dm2Sbi1IiIyPaXy1C8-Ip3CSICVal_VO_FKzVaQCfRVUImQmKuNuNXfKzqhnwAM1Cw_lyQVL8ew=@protonmail.com> (raw)

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

             reply	other threads:[~2017-03-31 20:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 20:29 praxeology_guy [this message]
2017-03-31 20:57 ` [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal Bram Cohen
2017-03-31 21:17   ` praxeology_guy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='1dvInLVM9fq2GjQVacau8gDyslYCCx_6dm2Sbi1IiIyPaXy1C8-Ip3CSICVal_VO_FKzVaQCfRVUImQmKuNuNXfKzqhnwAM1Cw_lyQVL8ew=@protonmail.com' \
    --to=praxeology_guy@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox