Make CFeeRate work with uint64_t sizes #23633

pull kiminuo wants to merge 1 commits into bitcoin:master from kiminuo:feature/2021-11-30-FeeRate-uint64_t changing 2 files +4 −4
  1. kiminuo commented at 10:16 am on November 30, 2021: contributor

    txmempool.h contains functions:

    • uint64_t GetSizeWithDescendants() const
    • uint64_t GetSizeWithAncestors() const

    A return value (i.e. uint64_t) of these functions can be used to instantiate CFeeRate. In the current master branch, this would require a cast to uint32_t because CFeeRate has the following constructor:

    https://github.com/bitcoin/bitcoin/blob/29074ba8364d4c0bf70121210222aff3fbf1e4df/src/policy/feerate.cpp#L12

    This PR attempts to remove the need for the casting.

    The PR’s commit is cherry-picked from sipa’s https://github.com/sipa/bitcoin/commits/202111_mempoolfr branch (see #21422 (comment)) which improves #21422.

    The PR is currently a draft as I get:

    0policy/feerate.cpp: In constructor CFeeRate::CFeeRate(const CAmount&, uint64_t):
    1policy/feerate.cpp:14:25: warning: narrowing conversion of num_bytes from uint64_t {aka long unsigned int} to int64_t {aka long int} [-Wnarrowing]
    2   14 |     const int64_t nSize{num_bytes};
    3      |                         ^~~~~~~~~
    4policy/feerate.cpp: In member function CAmount CFeeRate::GetFee(uint64_t) const:
    5policy/feerate.cpp:25:25: warning: narrowing conversion of num_bytes from uint64_t {aka long unsigned int} to int64_t {aka long int} [-Wnarrowing]
    6   25 |     const int64_t nSize{num_bytes};
    

    during compilation.

    Anyway, I would like to get some early feedback if the PR makes sense to you or not.

  2. Make CFeeRate work with uint64_t sizes fc5b15daf0
  3. DrahtBot added the label TX fees and policy on Nov 30, 2021
  4. sipa commented at 4:07 pm on November 30, 2021: member
    Please don’t @ mention people in PR descriptions. They’ll get github notifications every time j-random-altcoin cherry-picks them.
  5. maflcko commented at 4:11 pm on November 30, 2021: member
    Concept ACK, but please link to the commit that you are reverting
  6. DrahtBot commented at 4:39 pm on November 30, 2021: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #24305 (Docs: [policy] Remove outdated confusing comment by Xekyo)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  7. kiminuo commented at 6:12 pm on November 30, 2021: contributor

    Please don’t @ mention people in PR descriptions. They’ll get github notifications every time j-random-altcoin cherry-picks them.

    Fixed. Sorry for that.

  8. luke-jr commented at 11:20 pm on November 30, 2021: member

    I’m not sure this is a good idea. A block can only be at the very most 4 MB today, which uint32_t is more than sufficient for. Does the “fee rate” across ancestors/descendants actually matter for sizes larger than this? It doesn’t make sense for miners to take fees they won’t get into consideration…

    If anything, perhaps we should revisit where we get the combined fee rates, and make sure we ignore anything that wouldn’t fit in a block?

  9. maflcko commented at 7:12 am on December 1, 2021: member

    References:

    • This effectively reverts ce4a852475fc445be88685197ea48c19256e0401
    • Related discussion: #21422 (review)
  10. kiminuo commented at 1:25 pm on December 1, 2021: contributor

    Does the “fee rate” across ancestors/descendants actually matter for sizes larger than this?

    Maybe @sdaftuar can explain why uint64_t GetSizeWithDescendants() const returns uint64_t given that he added it 🙏. That would be helpful to decide whether to work on this PR more or just close it.

  11. luke-jr commented at 6:23 pm on December 1, 2021: member
    Perhaps the GetSizeWith* functions need to limit their scope to at most a single block of transactions. But then we also need to calculate the combined fee with that same scope. Ugh.
  12. DrahtBot added the label Needs rebase on Feb 22, 2022
  13. DrahtBot commented at 11:54 am on February 22, 2022: contributor

    🐙 This pull request conflicts with the target branch and needs rebase.

    Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a “draft”.

  14. DrahtBot commented at 7:03 am on July 25, 2022: contributor
    • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
    • Is it no longer relevant? ➡️ Please close.
    • Did the author lose interest or time to work on this? ➡️ Please close it and mark it ‘Up for grabs’ with the label, so that it can be picked up in the future.
  15. glozow commented at 6:52 pm on October 12, 2022: member
    Closing this as it has not had any activity in a while. If you are interested in continuing work on this, please leave a comment so that it can be reopened.
  16. glozow closed this on Oct 12, 2022

  17. bitcoin locked this on Oct 12, 2023

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: 2024-10-31 03:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me