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.
