How would we communicate these fees? Assuming that it won’t be via gossip, as we’re moving to one update per block in taproot gossip which wouldn’t be nearly reactive enough to protect against a sudden influx of traffic. Will we add proper error propagation for onion messages to be able to communicate your latest fee policy?
This also sounds like something that could be abused by an attacker if we’re not careful. I’d be interested in seeing an algorithm and some adversarial simulations that demonstrate how this would work!
I’d need to understand the details of the proposed scheme to answer this properly (specifically the above questions about dynamic fees). At the moment it’s unclear to me whether an OM failure can always be interpreted as a liquidity failure, and if we allow different failure modes (like insufficient fees failures) how incentives for forwarding nodes to be honest play out. I’d also worry that feeding OM data into pathfinding could open up new channel jamming vectors.