Electrum: Fee estimation on command line

[bsbits]

Electrum provide fee estimation on the GUI with excellent features like target blocks.

But is there anything similar or usable via command line ? I do not want to use an external service to compute or estimate the required fees.

[ecdsa]

if you run the daemon, it will use the same fee estimates as the GUI.
you need to open the GUI to set your fee preferences.

[bsbits]

Except I will be using electrum on servers as a hot wallet for my websites, so no GUI.

[ecdsa]

well, you can check what are the relevant configuration variables on another machine with gui, and set them using setconfig

[dabura667]

You could add your own CLI command to commands.py:

@command('n')
def getestimatedfee(self, number_of_blocks):
    """Returns the fee estimation from the server.
    smallest value is 2.
    """
    number_of_blocks = int(number_of_blocks)
    if number_of_blocks < 2:
        raise BaseException('number_of_blocks must be >= 2')
    return self.network.synchronous_get(('blockchain.estimatefee', [number_of_blocks]))

usage

electrum getestimatedfee

note: I have not tested this... @bsbits

[dabura667]

Oh, you want to set the dynamic fees without opening GUI? Sorry, I misread. @bsbits

electrum setconfig dynamic_fees True
to set the dynamic fees on. only need to be done once, and it will save to your config file.

electrum setconfig fee_level 3
To set the dynamic target to the 4th tick. (4 is the fastest, 3 is a 2 block estimate, 0 is the slowest dynamic fee setting)

Also just in case something gets sent by non-dynamic fees due to a bug, I might just set:

electrum setconfig fee_per_kb 300000
Maybe do this before the other two commands.

Now as long as you use the same user to run electrum (these commands modify the OS user's config, not global config) it should send using the dynamic fees you want.

[bsbits]

@dabura667 : amazing.

[TJC]

I have been using the command-line version of Electrum, and always manually calculating the fee to pass to the payto command. (ie. payto -f amount).

I've messed this up before, though, when I sent a transaction that was twice as many bytes as usual -- and so my fee was effectively half the usual. It took about twenty hours to get confirmed.

While I now know from this issue about how to configure dynamic fees, there's still work to be done. I'd love it if the "help payto" command could let the user know how to enable dynamic fees.

Perhaps add a parameter to payto like --dynamicfee [fastest|fast|slow|slowest] ?

[SomberNight]

There is now a getfeerate command in master since https://github.com/spesmilo/electrum/commit/98663d7e20bb391febaffe213bb52b763717e135

[maxmalysh]

getfeerate doesn't accept parameters.

Sometimes it's important to send transactions programatically using a different fee_level. You can do this using GUI, but you can't using the command line or API. As @TJC said, it would be nice to add a parameter either to getfeerate or to payto.

@SomberNight what do you think of this? I can make a PR if you wish.

[Platinumwrist]

That's great idea @TJC

[SomberNight]

@maxmalysh what parameter would you like to pass it?

There are currently two dynamic fee estimation methods available (in the GUI):

• ETA based estimates (backed by estimatesmartfee from Bitcoin Core)
• mempool based estimates (targeting a depth in the current mempool)
  They don't have the same granularity (i.e. 5 slider positions "fee levels"(?) for ETA, 7 for mempool).

I guess getfeerate could be modified to take two optional parameters; to specify the estimation method, and the fee level. What would "fee level" be though? Keep in mind that it might be desirable to be able to increase/decrease granularity without affecting this command (e.g. for mempool estimation, fee level could range between 0-6 incl but if we introduced 4 more slider positions then 6 would suddenly be near the middle instead of at an extreme).
Assuming the slider in the GUI always has sane values, the "fee level" argument could just be a float between 0.0-1.0, and map to the closest slider position, I guess... :P

[TJC]

Regarding the granularity settings in the CLI: Why not make it take a float as the argument, between 0 and 1, then map that to the 5 or 7 positions? This is future-proofed too -- if the bitcoincore or mempool systems change to have more (or less) discrete levels, then it'll still continue to work.

[TJC]

I think you might have actually suggested that in jest in your last comment, but... it actually feels like a sane idea to me.