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

[Feature request] switch for the miner fee randomization in the config #1009

Closed
openoms opened this issue Sep 8, 2021 · 3 comments · Fixed by #1033
Closed

[Feature request] switch for the miner fee randomization in the config #1009

openoms opened this issue Sep 8, 2021 · 3 comments · Fixed by #1033

Comments

@openoms
Copy link
Contributor

openoms commented Sep 8, 2021

from IRC:

Is there a way to switch off the miner fee randomization in the QT or at least in CLI?
I'd like to be able to sweep a UTXO to an LN channel cheap as possible. Currently need to leave around 1000 sats to be send a fixed amount even with 1 input - 1 output.

waxwing_
openoms, no you'd have to change it in the code i'm afraid
see jmclient.blockchaininterface.BitcoinCoreInterface.estimate_fee_per_kb
...
the argument for having it not configurable is 'protect people and don't load them cognitively', but the counterargument is perfectly reasonable. should be a trivial PR i think.

@chris-belcher
Copy link
Contributor

How about making the randomization amount be configurable, in the same way that yield-generators parameters are (e.g. cjfee_factor, txfee_factor and size_factor) By default the value would be finite, but if the user wants to turn off the miner fee randomization they set it to zero.

@kristapsk
Copy link
Member

I am for adding new setting for tx feerate randomization (tx_fees_factor?), should default to current behaviour (0.2).

@openoms
Copy link
Contributor Author

openoms commented Sep 30, 2021

yes, a tx_fees_factor option is exactly what is needed!

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

Successfully merging a pull request may close this issue.

3 participants