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

settxfee allows setting below required amounts #187

Closed
raedah opened this issue Apr 18, 2016 · 9 comments
Closed

settxfee allows setting below required amounts #187

raedah opened this issue Apr 18, 2016 · 9 comments

Comments

@raedah
Copy link
Contributor

raedah commented Apr 18, 2016

> settxfee 0     
true
> getwalletfee
0

But when trying to do a transaction, this error comes up.
-32603: -22: TX rejected: transaction --- has 0 fees per kb which is under the required threshold amount of 1000000

The expected behavior would be to have a minimum value that settxfee is allowed to be set to, and to return an error telling the user that they can not set the txfee below the minimum amount, and tell them what the minimum amount is.

Also wondering, why are the set and get cmds for this feature spelled differently?

@raedah
Copy link
Contributor Author

raedah commented Apr 18, 2016

Related to issue #171 and its pr #172 where a user could end up accidentally setting a txfee that is way too high, I suggest a safe guard upper bound sane limit on what txfee can be set as well.

@alexlyp
Copy link
Member

alexlyp commented Apr 19, 2016

I disagree that the expected behaviour would be for a minimum to be set internally.

If people want to set these fees to wacky values, that's their responsibility to use sensible numbers. The nodes/miners will accept or deny based on their own rules

Even if we did have an internal lower/upper bound, what would those bounds be?

@alexlyp
Copy link
Member

alexlyp commented Apr 19, 2016

Well actually after talking with devs a bit more about it, I think coming up with a sensible upper bound makes sense to avoid people setting fees to a crazy number.

But there will be no lower bound, if people want to set them all the way to 0 then so be it.

@raedah
Copy link
Contributor Author

raedah commented Apr 19, 2016

@alexlyp Low fee's are already invalid. Error: "TX rejected: transaction has 0 fees per kb which is under the required threshold amount of 1000000". Instead of letting a user set it to a value which is going to cause an error later, it would be more helpful to just let them know when they try to set it that it is not going to work.

@alexlyp
Copy link
Member

alexlyp commented Apr 19, 2016

Well problem there is that err is not coming from wallet, that is a dcrd mempool fee threshold acceptance err. The tx fails due to the rules set therein, there is nothing limiting you (nor should there be) in wallet from sending a tx that has fees that are below the threshold. Mempool policy code should definitely stay of wallet.

@raedah
Copy link
Contributor Author

raedah commented Apr 19, 2016

What is the use case for for sending a transaction with a fee below the mempool fee threshold?

@jrick
Copy link
Member

jrick commented Apr 20, 2016

You could be using a newer version of dcrd which lowers the default relay fee, or you changed the relay fee policy with a config option. dcrd and dcrwallet are two distinct projects and they need to be able to work together when the other is using non-standard options.

@alexlyp
Copy link
Member

alexlyp commented Apr 20, 2016

dcrd PR decred/dcrd#124 fixes the ability to send transactions with too high of fees. If a user wishes to skip this check they can set --allowhighfees=true, otherwise it will always check to see that the fee isn't greater than 100x of the min fee.

And I think the devs are in agreement that adding a check in wallet for too low of fees would work against the centralization of mempool policy in daemon. Thanks for opening the issue, nonetheless.

@alexlyp alexlyp closed this as completed Apr 20, 2016
@raedah
Copy link
Contributor Author

raedah commented Apr 20, 2016

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants