Rizful.com on Nostr: Interesting. The first think you are discussing ... "The sender's wallet used a lower ...

Interesting. The first think you are discussing ... "The sender's wallet used a lower fee because it saw that in the network graph, which didn't relay fresh data well due to the protocol's significant delay. " -- this is something I've seen a lot on the Lightning Network, but I've never seen it quantified. But anecdotally, there do seem to be nodes that are used to for payments which often "cache" old fee information from the network. My assumption is that many might be mobile clients with poor connectivity. It's actually for this reason that none of our nodes use "fast" automatic fee changes ... my experience is that you shouldn't change fees more than maybe once or twice a week for any given channel, because of this "caching" behavior. I've also seen attempted payments which are clearly using fee information that is several days out-of-date.

Regarding this second issue, you write: "our Lightning Network server would simply send a packet to the sender indicating that funds can't be sent through this channel temporarily." Do you mean like with LND's "updatechanstatus" API? https://lightning.engineering/api-docs/api/lnd/router/update-chan-status/ .... if so, wouldn't this prevent your depleting channel from "refilling" from the other side? Or maybe you are referring to a different strategy?