Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[qt] Update coin control and smartfee labels #6887

Merged

Conversation

maflcko
Copy link
Member

@maflcko maflcko commented Oct 25, 2015

This will sync the qt labels with the wallet's fee code.

@luke-jr
Copy link
Member

luke-jr commented Oct 25, 2015

So the idea here is to use the min relay fee instead of the wallet's configured fee, whichever is higher?

@maflcko
Copy link
Member Author

maflcko commented Oct 25, 2015

Yes, it's just what the wallet already does. This should make qt consistent again. C.f.

  • 037b4f1 (Make mining fee policy match relay fee policy) and
  • aa279d6 (Enforce minRelayTxFee on wallet created tx)

@laanwj laanwj added the GUI label Oct 26, 2015
@jgarzik
Copy link
Contributor

jgarzik commented Oct 27, 2015

ut ACK

@@ -2120,6 +2120,11 @@ bool CWallet::CommitTransaction(CWalletTx& wtxNew, CReserveKey& reservekey)
return true;
}

CAmount CWallet::GetRequiredFee(unsigned int nTxBytes)
{
return std::max(minTxFee.GetFee(nTxBytes), ::minRelayTxFee.GetFee(nTxBytes));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sad to see another coupling between the Wallet and the Mempool/Node. But it's already all over.
Ideally the wallet should not directly access global mempool variables instead it should get data over a general interface.

@jonasschnelli
Copy link
Contributor

Makes sense.
utACK.

@maflcko maflcko force-pushed the MarcoFalke-2015-qtMaxMin_Fee_and_Max_Fee branch from 7456618 to 51a384c Compare November 3, 2015 08:08
@maflcko
Copy link
Member Author

maflcko commented Nov 3, 2015

@morcos This is addressing your issue #5202. Mind to review?

@morcos
Copy link
Contributor

morcos commented Nov 3, 2015

I think most of the pull makes sense, but I'd save removing the AbsurdFee check until we replace it with something better. Having the only effective high fee check be the ATMP check is dicey since that depends on minRelayTxFee which people might be adjusting for other reasons. Also I'm not sure how this is meant to work with #6726. I don't like the idea of having less and less checks for accidental high fees. I just think we should rework them to be better organized.

@laanwj
Copy link
Member

laanwj commented Nov 4, 2015

I agree with @morcos. The absurdfee check is just a belt-and-suspenders check, in case something goes wrong due to a bug in another part of the code. I don't feel good about removing it.
I also don't think that change belongs in a "Update coin control and smartfee labels" pull.

@maflcko maflcko force-pushed the MarcoFalke-2015-qtMaxMin_Fee_and_Max_Fee branch from 51a384c to 53238ff Compare November 4, 2015 11:18
@maflcko
Copy link
Member Author

maflcko commented Nov 4, 2015

@laanwj I also don't think that change belongs in a "Update coin control and smartfee labels" pull.

Still, the fee label behaves wrong and needs update, but I force dropped the last commit to open a new PR for this...

@laanwj laanwj merged commit 53238ff into bitcoin:master Nov 5, 2015
laanwj added a commit that referenced this pull request Nov 5, 2015
53238ff Clarify what minrelaytxfee does (MarcoFalke)
abd8b76 [qt] Properly display required fee instead of minTxFee (MarcoFalke)
@maflcko maflcko deleted the MarcoFalke-2015-qtMaxMin_Fee_and_Max_Fee branch November 5, 2015 17:55
zkbot added a commit to zcash/zcash that referenced this pull request Dec 18, 2019
Bitcoin 0.12 cleanup PRs 2

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6631
- bitcoin/bitcoin#6664
  - Only the first commit (we already had the second through bitcoin/bitcoin#6825).
- bitcoin/bitcoin#6669
- bitcoin/bitcoin#6887
  - Only the non-QT parts.
- bitcoin/bitcoin#6962
- bitcoin/bitcoin#6822
  - Only first and third commits (we already had the second through an earlier PR).
- bitcoin/bitcoin#7136
  - Excludes Travis CI changes, and fixes to documents we don't have anymore.
- bitcoin/bitcoin#7084
- bitcoin/bitcoin#7509
- bitcoin/bitcoin#7617
- bitcoin/bitcoin#7726

Part of #2074.
furszy added a commit to PIVX-Project/PIVX that referenced this pull request Jun 2, 2020
4038de4 [QA] Restore 'feature_fee_estimation.py' functional test (random-zebra)
988f349 [qt] Properly display required fee instead of minTxFee (random-zebra)
c5c9df0 [Trivial] Fix typos (random-zebra)
a8fa99b [Trivial] Remove redundat check in ContainsZerocoins (random-zebra)
8ebcbcd PolicyEstimator: exclude zerocoin spends when computing estimates (random-zebra)
b67049b Create new BlockPolicyEstimator for fee estimates (random-zebra)

Pull request description:

  This introduces the new fee and priority estimation code described here <https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06405.html>.

  Instead of calculating the median fee for each possible number of blocks needed to confirm, the new code divides the possible fee rates into buckets (spaced logarithmically) and keeps track of the number of blocks needed to confirm for each transaction in each bucket.

  Backports:
  - bitcoin#5159
  - bitcoin#6887

  except for the functional test (`smartfees.py`) which is based on an older version of the framework.
  Instead I've restored a more recent `feature_fee_estimation.py` (commenting out the check for `estimatesmartfee` which can be reintroduced once bitcoin#6134 is backported).

  Additional commits exclude zerocoins txes from the estimates calculation, as they have fixed fee/priority.

ACKs for top commit:
  Fuzzbawls:
    ACK 4038de4
  furszy:
    ACK 4038de4 and merging

Tree-SHA512: 25777af469f7fa84d2dab991544392bea8418bccb4d2c23113de2c6ed7047891bdaedad1728cb04ba343e82f4bc0c1446f88e28def698dd25168769abf8620bb
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants