API: GetMinFee modes #677

pull luke-jr wants to merge 2 commits into bitcoin:master from luke-jr:minfee_modes changing 3 files +13 −5
  1. luke-jr commented at 3:49 AM on December 3, 2011: member

    This replaces the fForRelay flag in the GetMinFee function with an enum mode parameter (GMF_{BLOCK,RELAY,SEND}), to allow more fine-tuned fee rules. The end goal is an API for allowing users to customize their fee schedules.

  2. luke-jr commented at 3:51 AM on December 3, 2011: member

    This change was discussed in #bitcoin-dev during the 0.3.22 release cycle. At least BlueMatt and ArtForz supported it, and jrmithdobbs recommended using an enum instead (it was an int at the time). Since we were at rc5 at the time, sipa wanted to stick with his boolean-only rewrite temporarily and wait to merge this for 0.3.23.

  3. in src/main.h:None in d8761995da outdated 
     529 | @@ -523,10 +530,10 @@ class CTransaction
 530 |          return dPriority > COIN * 144 / 250;
 531 |      }
 532 |  
 533 | -    int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=true, bool fForRelay=false) const
 534 | +    int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=true, enum GetMinFee_mode mode=GMF_BLOCK) const
 535 |      {
 536 |          // Base fee is either MIN_TX_FEE or MIN_RELAY_TX_FEE
 537 | -        int64 nBaseFee = fForRelay ? MIN_RELAY_TX_FEE : MIN_TX_FEE;
 538 | +        int64 nBaseFee = (mode == GMF_RELAY) ? MIN_RELAY_TX_FEE : MIN_TX_FEE;
    sipa commented at 1:54 PM on December 4, 2011:

    I believe this should be (mode == GMF_RELAY || mode == GMF_BLOCK), if you want to leave the actual fee policy intact.

    luke-jr commented at 2:24 PM on December 4, 2011:

    Good catch :)

    luke-jr commented at 2:27 PM on December 4, 2011:

    Actually, while this is literally true, is the actual fee policy supposed to be allowing a fee based on 0.0001 BTC into blocks? I thought 0.0005 BTC was the current bitcoind-default fee baseline, and 0.0001 BTC was just being relayed for a potential future drop... if so, this is fixing a bug here!

  4. TheBlueMatt commented at 6:52 PM on December 5, 2011: member

    Although allowing users to easily do whatever they want for fees is nice, its really not the way to go. If you want to make it easier for miners to customize fee schedule (which should absolutely be done), you also have to make sure the customization options still (attempt to) force the miners to keep the original incentivization (dont think thats a word...) structure or you risk issues like the downward-spiraling fee issue. So until someone makes a nice fee algorithm, I would have to vote strongly against anything which allows for easier fee customization.

  5. luke-jr commented at 6:58 PM on December 5, 2011: member

    Change of heart? You supported it before... but now you prefer a more monopolistic control hierarchy by intentionally trying to force things on people? :(

  6. TheBlueMatt commented at 7:08 PM on December 5, 2011: member

    No, I've always supported allowing people to customize fee scheduling, just not unless all the many, many issues with it are dealt with. That said, this is such a minor step in that direction that my issues are fairly irrelevant. Anyway, a change like this would be required if a nice customizeable fee-scheduling algorithm came along. I was just making sure to remind everyone of the issues at hand when dealing with fee customization, and making sure I got that out there so that a pull-request that allows the settings to be easily changed via RPC doesnt get merged before I can get that out there.

  7. realsolid commented at 7:45 AM on December 6, 2011: none

    You can't really have custom fees in a client unless you propagate ALL transactions by default. Otherwise transactions are going to be firewalled by the nodes which don't accept them. There are currently rules by which transactions are propagated so I can't see how custom fees can be enabled by miners.

  8. TheBlueMatt commented at 2:16 PM on December 6, 2011: member

    That is, in fact, the point of this pull it allows inividuals to have different fee policies depending on the situation (mining, relaying, or sending)

    realsolid reply@reply.github.com wrote:

    You can't really have custom fees in a client unless you propagate ALL transactions by default. Otherwise transactions are going to be firewalled by the nodes which don't accept them. There are currently rules by which transactions are propagated so I can't see how custom fees can be enabled by miners.

    Reply to this email directly or view it on GitHub: #677 (comment)

  9. realsolid commented at 11:00 PM on December 6, 2011: none

    What is the point in allowing individuals to set it when a client is connected to 8 nodes which don't share your fee relay settings? His transaction will never get out if it's too large. Unless you change the default "pass on" behaviour then you're relying upon a random collection of fee settings that will delay, and worst case block people trying to send transactions until they try a variety of different fee settings (after scrubbing their wallet of course).

  10. luke-jr commented at 11:36 PM on December 6, 2011: member

    This isn't a user-visible change yet, and probably won't be until giving up on and/or modifying transactions is supported. The point is to take steps toward that eventual goal. This particular change is useful for miners.

  11. TheBlueMatt commented at 11:51 PM on December 6, 2011: member

    Thats what addnode is for.

    realsolid reply@reply.github.com wrote:

    What is the point in allowing individuals to set it when a client is connected to 8 nodes which don't share your fee relay settings? His transaction will never get out if it's too large. Unless you change the default "pass on" behaviour then you're relying upon a random collection of fee settings that will delay, and worst case block people trying to send transactions until they try a variety of different fee settings (after scrubbing their wallet of course).

    Reply to this email directly or view it on GitHub: #677 (comment)

  12. sipa commented at 8:35 PM on December 13, 2011: member

    ACK

  13. jgarzik commented at 8:44 PM on December 13, 2011: contributor

    At a minimum, it would be nice to separate the policy change from the cleanup, i.e. one commit introduces the enum changes, with no behavior/policy changes in that commit

  14. Bugfix: fForRelay should be false when deciding required fee to include in blocks
    During the rushed transition from 0.01 BTC to 0.0005 BTC fees, we took the
approach of dropping the relay and block-inclusion fee to 0.0005 BTC
immediately, and only delayed adjusting the sending fee for the next release.
Afterward, the relay fee was lowered to 0.0001 BTC to avoid having the same
problem in the future. However, the block inclusion code was left setting
fForRelay to true! This fixes that, so the lower 0.0001 BTC allowance is (as
intended) only permitted for real relaying.
    a880b29cab
  15. GetMinFee takes a mode parameter (GMF_{BLOCK,RELAY,SEND}) instead of fForRelay dbbf1d4a48
  16. gavinandresen referenced this in commit 781c06c0f5 on Dec 20, 2011
  17. gavinandresen merged this on Dec 20, 2011
  18. gavinandresen closed this on Dec 20, 2011
  19. coblee referenced this in commit bd33c24845 on Jul 17, 2012
  20. jpentland referenced this in commit 3f4d5c4c7d on Feb 7, 2016
  21. kallewoof referenced this in commit 751c0771da on Oct 4, 2019
  22. sipa referenced this in commit d5cd9db7a3 on Nov 19, 2019
  23. sipa referenced this in commit de659898b6 on Jan 21, 2020
  24. sipa referenced this in commit 36362dfb90 on Jan 23, 2020
  25. Losangelosgenetics referenced this in commit 0133a1465b on Mar 12, 2020
  26. Losangelosgenetics referenced this in commit cbcf2a5a3a on Mar 12, 2020
  27. jnewbery referenced this in commit 85e7d06351 on Mar 17, 2020
  28. sipa referenced this in commit 4977ac14d3 on Mar 18, 2020
  29. sipa referenced this in commit 5bf7fb5baa on Mar 18, 2020
  30. sipa referenced this in commit fb2a05e468 on Mar 19, 2020
  31. sipa referenced this in commit 497fad6f09 on Mar 21, 2020
  32. sipa referenced this in commit eae016f117 on Mar 22, 2020
  33. sipa referenced this in commit 4e37a7c2cb on Mar 27, 2020
  34. jnewbery referenced this in commit 9696dea839 on Apr 16, 2020
  35. jnewbery referenced this in commit a541fd0e87 on Apr 19, 2020
  36. sipa referenced this in commit c308759ea5 on Apr 19, 2020
  37. sipa referenced this in commit 4eaec32f1c on May 2, 2020
  38. sipa referenced this in commit ef7117193c on May 22, 2020
  39. sipa referenced this in commit 67f232b5d8 on Jun 9, 2020
  40. stackman27 referenced this in commit 78cde6f8c7 on Jun 26, 2020
  41. DrahtBot locked this on Sep 8, 2021
Contributors
luke-jrsipaTheBlueMattrealsolidjgarzik
Linked (view graph)
#705 2011-12-16 "next"#25895 importdescriptors hanging on importing/updating descriptor with large range
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-14 15:16 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me