Regarding your last question, I meant that the Lightning Network protocol includes an onion packet type, when a payment fails due to insufficient balance. It needs to be pushed further. Then the intermediate node on the route sends back an onion to the sender containing an error code indicating that the channel temporarily cannot send the payment due to fee changes. It also specifies the new fees in the same onion. I haven't looked at it right now, I don't have the protocol on hand, but it's definitely there. And it's described somewhere in the Bolt specifications.
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?
Discussion
I got a bit confused. Also, answering your question, I mixed up a bit by indicating the wrong type of error. But generally, when a payment cannot be sent further because, for example, we don't have enough balance on our side to send it further, an onion is also sent, which indicates a temporary error code, and the onion is also sent back to the sender. From it, they can see which node along the way sent it, so they don't send the same-sized payment through the same channel again.
Actually, I was talking in the context that instead of specifically regulating fees in channels that are drained, you can just rely on such packets to be sent to the sender if the payment cannot go through due to insufficient liquidity. And if there is still enough liquidity to make the payment, even if it's small, let such a payment go through at a fixed rate that was there at any balance of our channel. I hope I expressed myself more clearly.
You wrote....
"you can just rely on such packets to be sent to the sender if the payment cannot go through due to insufficient liquidity"
.... Right -- "temporary_channel_failure" -- here https://github.com/lightning/bolts/blob/2b9c73b48c1920df8e7e867d110fab2d720a059b/04-onion-routing.md?plain=1#L1157 .
The issue is that hitting failures like this has the effect of increasing payment latency for users, and also, if there are too many failures, the payment will time out entirely. Shouldn't we, for the sake of users, be trying to insulate payers from potential failures?
And ....isn't a good way to do THAT is to simply signal to the network "hey, don't use this channel in this direction, I'm signaling this by putting my fees high"..... ?
I would think rather than fees, what you are both describing is the perfect use case for the max_HTLC setting? I know some noderunners don't use this setting for various reasons, but when it is used can signal to the network available liquidity (or lack of) while still minimizing or even preventing temportary_channel_failures.
Sorry that was the incorrect deeplink to the Bolts.. here is where I intended:
" - if during forwarding to its receiving peer, an otherwise unspecified,
transient error occurs in the outgoing channel (e.g. channel capacity reached,
too many in-flight HTLCs, etc.):
- return a `temporary_channel_failure` error."