minRelayTxFee should be calculated on weight, not vbytes. aka “vbytes must die” #13283

issue rustyrussell openend this issue on May 20, 2018
  1. rustyrussell commented at 0:54 am on May 20, 2018: contributor

    By default, bitcoin core has minRelayTxFee of ‘0.00001000’ or 1000 satoshi per 1000 bytes.

    This should be the same as 250 satoshi per kiloweight, but it’s not since it internally uses vbytes (which rounds up). As a result, modern (segwit-only) software must perform hacks to ensure that it generates transactions which propagate, and authors write angsty, whiny commit messages:

    https://github.com/ElementsProject/lightning/commit/2e687b9b352c9092b5e8bd4a688916ac50b44af0

    What behavior did you expect?

    Transactions with exactly 250 satoshi per kilosipa should propagate.

    What was the actual behavior?

    Only one in four transactions like this will propagate, the rest will be rejected.

  2. fanquake added the label TX fees and policy on May 20, 2018
  3. GreatSock commented at 4:59 pm on May 20, 2018: contributor

    I made an attempt at fixing this: https://github.com/GreatSock/bitcoin/commit/20a5b18358f94024114cb2208c308001ed4ee42a

    But I don’t feel like I understand what I’m doing enough to make a serious pull request.

  4. sipa commented at 11:43 pm on May 21, 2018: member

    This isn’t (or at least, wasn’t) done because of fears of confusion in suddenly changing all feerates by a factor of 4, and risking people overpaying because they use a fee estimate per byte in a place where one per weight is expected. The goal was that users would never be exposed to the concept of weight (which governs consensus rules), and could just continue using (v)bytes.

    All fee logic uses vbytes for that reason. This does not only apply to minRelayTxFee but also prioritization, dust logic, transaction replacement, … I don’t see how there is a problem with that. It could be changed, but it would be a pretty invasive thing.

  5. rustyrussell commented at 7:38 am on June 20, 2018: contributor

    Pieter Wuille notifications@github.com writes:

    This isn’t (or at least, wasn’t) done because of fears of confusion in suddenly changing all feerates by a factor of 4, and risking people overpaying because they use a fee estimate per byte in a place where one per weight is expected. The goal was that users would never be exposed to the concept of weight (which governs consensus rules), and could just continue using (v)bytes.

    All fee logic uses vbytes for that reason. This does not only apply to minRelayTxFee but also prioritization, dust logic, transaction replacement, … I don’t see how there is a problem with that. It could be changed, but it would be a pretty invasive thing.

    It’s horrible for modern users, which will eventually outweigh legacy ones. You can’t just say “bitcoin uses weight now, not bytes”; You have to know both. For example, both lightning and GreenAddress were broken by the “vbytes for fee calculation” rule; fortunately they mentioned it to me so I could figure out WTF was going on w/ lightning.

    Regarding APIs generally:

    1. Adding “vbytes” fields was contaminated thinking, but it’s too late now.
    2. I agree that such a change would be invasive and hard; in particular care would be needed that these rules got looser, not tighter, and other nodes wouldn’t start banning new nodes who fwd txs they consider nonstandard, and I’m sure other things I haven’t thought of.
    3. minRelayTxFee, dust logic, transaction replacement and IsStandard() are APIs which upper layers (like lightning) need to know; though I hate that. They should be as clear as possible and not changed without broad consultation; certainly not tightened.

    Since I consider stuff-on-top-of-Bitcoin to be at an early phase, I consider simplifying these APIs to be important to avoid contaminating everything up-stack with legacy.

  6. maflcko added the label Brainstorming on Dec 25, 2018
  7. darosior referenced this in commit 05375845a2 on Nov 19, 2019
  8. darosior referenced this in commit cd5c8c2b42 on Nov 22, 2019
  9. darosior referenced this in commit 96e702e882 on Nov 22, 2019
  10. pinheadmz commented at 2:27 pm on April 27, 2023: member
    This issue is unlikely to be fixed in Bitcoin Core. We’ll close for now, but feel free to open another issue or pull request with a fix.
  11. pinheadmz closed this on Apr 27, 2023

  12. bitcoin locked this on Apr 26, 2024

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-11-17 15:12 UTC

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