I built the #[11] precisely for that. Though it sources the data from the mempool.space websocket API, not estimatesmartfee.
Discussion
Nice bot, thank you for building!
And now just look at the No Prio Fee:
1 sat/vByte transactions were last included in a block on 7th March and would also have been purged since.
I like to pay only the minimum fee so find it important to see the floor. To be clear I am most worried about the automatic fee calculation for the commitment transactions on the connected lightning nodes.
Fair point. I didn't thought about that and it's the first time someone brings it up to me.
I concede that an operator of a LN node backed by an Ordisrespector Bitcoin Core has to pay extra attention to both mempools if he wants to close a channel (for now).
The mempool.space api considers the current mempool. But I bitcoind’s estimator looks more at recently mined blocks. You can restart bitcoind with persistmempool=0 and get the similar estimates as with 500gig mempool. One of the reasons I pointed my lnd node to my ordisrepector node was to try to decrease the sweep fees lnd paying (conf target 6). But it made little/no difference and I was paying 20 s/vb when 6 or 7 would’ve put it in the next block.
did you try:
bitcoind.estimatemode=ECNOMICAL
in the in the lnd.conf ?
Yes. However, for block target 6, bitcoind returns the same fee rate for conservative/economical which is 13 s/vb right now
That is clearly because inscriptions are taking uo the lower fee bands. Once the mempool empties more or inscriptors pay more the problem will be present at 6 block targets as well.
Stuck transactions for channel opens and closes are a major headache.
Do you happen to know if LND, Core Lightning and Eclair's onchain wallets support RBF?
Yes, all transaction done by lightning clients are RBF enabled, but can be complicated for the channels due to the multisig.
LND: https://lightning.engineering/api-docs/api/lnd/wallet-kit/bump-fee
not familiar with Eclair and LDK does surely have procedures for this too.
Coming soon...
https://github.com/ZeusLN/zeus/releases/tag/v0.7.4-beta1
* **Fee bumping**
* Channel sorting and filtering
* Default invoice settings
* Single channel view redesign
[...]
I guess my point is running the patch doesn't make the problem worse in that lnd/bitcoind is not underestimating fees because of it. If anything, a very slight positive may be that lnd tx are not being purged from your local bitcoind mempool making it easier to CPFP.
I didn't expect to get schooled today. Thanks for these insights.
This is just my observation from running the patched node for the past month which included a few hours(?) the mempool was actually clearing 1 s/vb txs. I do recommended running a patched node in parallel if you can to see for yourself. I just added 2 lines to lncm/bitcoind Dockerfile to get it going.