A c-lightning user was having problems in that their fee estimates were so far out of sync with their peers that channels were being closed. Turns out he had ‘blockonly’ in his config.
Expected behavior
estimatesmartfee would fail.
Actual behavior
estimatesmartfee gives a result, but it doesn’t seem linked to reality. Perhaps from before blocksonly was enabled?
-connect=$(SOME_NO_TX_RELAY_NODE)). Not sure if this is possible with the current fee estimator design. @morcos any thoughts on this?
I haven’t looked at this in a while, but I thought the behavior was that if you had relatively recent estimates (which would only be the case if you’d been receiving transactions and your node was in sync) then estimatesmartfee would continue reporting those estimates for some period of time until the data was old enough that they were stale. This would happen naturally since the estimates use a exponentially decaying moving average and would happen quicker for estimates for shorter confirmation times. It’s possible it doesn’t work quite like this, or this doesn’t aggressively enough disable estimates, but I don’t know without further investigation.
For a non-lightning use case, the slightly stale estimates are still designed to be good enough to be usable for getting transactions confirmed and I think make more sense than having no estimates. I’d never considered a design goal of trying to keep estimates in sync with peers.
I was that user. :)
What I recommend is that if blocksonly is enabled, the algorithm should take in consideration only the fees already paid in the last blocks and discard the ones of the mempool, because obviusly there is no mempool.
I have some logs in c-lightning, the last recent error is:
CHANNELD_NORMAL:update_fee 5046 outside range 9345-186900
for a normal channel close tx, the ID is 92f83af6a1459d449803824d724e1333cdb45a86b22e73ae27438aa7f897402d
I think the channel closed on 3th September. The node was running in blocksonly mode for quite a few weeks.