GUI fee estimator may be inaccurate #8979

Got a report on IRC. Someone did create a TX with 0.13 GUI (did startup core GUI, ran for 30 min and sent tx). TXID: 627a15a1700cd59d2f5cdd2ce74c869bd1e42d55a3ede27ebbc5b3bd9cd9f640 The feerate is surprisingly low: 0.00006083 BTC.

That's not the feerate, that's the fee. The feerate is about 27 sat/byte which is a bit low, but not ridiculously slow.

Doesn't the GUI start with a default target of 25 blocks? That could have been not far off the right feerate for a target of 25. However, my node now says 56 sat/byte though for a target of 25, so what is more likely the case is one of two things:

1. The node was new and didn't have enough data to do any fee estimation so it used the default of 20 sat/byte.
2. The node had old fee estimation stats from last time it was run and fees were lower, and 30 mins isn't nearly enough to have the new stats outweigh old data (takes on the order of a couple of days).

I have done other work on fee estimation to address both of those problems but I abandoned it quite some time ago as fee estimation seemed not a very popular topic. I can revisit it at some point.

Would there be objections in changing the default target from 25 blocks to DEFAULT_TX_CONFIRM_TARGET == 2?

@jonasschnelli ACK. I think that would help reduce the complaints about slow confirmations

My personal preference would not be to mess around with the defaults any more unless and until we have potentially a better system and different defaults make more sense. If people are speed sensitive there is a giant slider staring them in the face. But I don't feel strongly enough to argue about it.

The only objection I have is that bitcoin-core's GUI uses a confirmation-target of 25 as the "normal" confirmation-speed where most other wallets are using something between 2 and 6 and, while core's internal wallet accessed over RPC use 2 as default (for send**/fund).

Other wallets do many inadvisable things. I don't really care if you change this, but 25 blocks frankly makes a lot more sense as a default than 2.

Anything left to do here after #8989 and #9036?