htlcswitch+gossip: recognize prior routing policies for a period of time after a new update

[Roasbeef]

Related to this spec PR: lightning/bolts#1001

This should be straight forward enough: keep around two copies of our policy, and check both when we need to make a forward/reject decision.

We might want to allow nodes to also opt out of this behavior?

[alexbosworth]

Would never want this on my own nodes so an opt out would be appreciated to avoid needing to do htlc interception

[shaurya947]

Hi @alexbosworth , I've been looking for potential issues to start contributing, and would like to attempt this.

I was hoping to get some clarity from you regarding the below:

• If a 10-minute window is required as per BOLT-7, and we say that lnd is fully compatible with BOLT-7, would allowing opting out conflict with this?
• If we do allow opting out, would that best be achieved through a config flag in lnd.conf?
• The pointers given by @Roasbeef seem quite comprehensive (thanks!). I am yet to dive deep into the code for this particular task, but would it be an acceptable strategy to start a 10-minute timer in a go routine (using time package) when a channel update is broadcasted, and discard the old policy when the timer is up?
• What should be the expected behavior in case another update announcement takes place before the first 10-minute timer expires?

[alexbosworth]

I think people can optionally change their node policies however it makes sense to them, another maybe better way to approach this is in the policy API call, allow it to set the flexibility there

In practice we've seen people have their entire channel liquidity drained in around 10 minutes, so practically it could cause problems if it's not configurable

[ellemouton]

I am yet to dive deep into the code for this particular task, but would it be an acceptable strategy to start a 10-minute timer in a go routine (using time package) when a channel update is broadcasted, and discard the old policy when the timer is up?

I think a simpler way (and a more restart-robust way) would be to add a timestamp associated with a policy so that you can just check the timestamp to know if you should still consider the prior policy

[shaurya947]

Thanks for the feedback @ellemouton , your suggestion makes sense. I will attempt to put together a rough outline of a plan in the next couple days and share that here 🙂

[alexbosworth]

A tradeoff for enabling this would be that node operators would be economically incentivized to make their fees higher than otherwise and it will reduce market forces that can help prioritize liquidity traffic.

For example, if I am selling apples, and sometimes I experience a surge of demand, I can just increase my price for an apple to adapt to new market conditions. However if I can no longer increase my price quickly, let's say I can only increase my price after 1 week of warning, then I will be more likely to charge a higher price for an apple just in case there is this surge. And for someone who really wants an apple, more than anyone else, instead of being able to buy an apple at a higher price they will see a sold out market with no apples. This is an example of market inefficiency

[shaurya947]

Hey @alexbosworth I see you point, but reading through the original bolt PR, it seems that the aim is to allow for just enough time for channel update announcements to propagate to a critical mass of the graph.

I guess the other side of your example would be that if the apple seller's price-change-announcement takes a few minutes to be observed by most of the market, within those few minutes you may have buyers coming with stale price data only to be turned away. That would also be market inefficiency? Not sure which kind is worse?

Either way, do we need to build more high-level consensus here before discussing implementation details? How should I go about doing that? Whom should I include and how?

(also happy to find something else to do if the current behavior isn't much of a problem and the proposed fix introduces trafeoffs that might be perceived as potentially worse.. just need some direction to focus my efforts 🙏 )

[alexbosworth]

In LND an invalid fee rate will be returned with an error showing the valid fee rate, so they can just retry the payment, that is the behavior already. Definitely though there is an issue in that buyers may see a low fee, be attracted and fail, however this may also be the case in the ten minute example because at a low fee the channel is more likely to deplete its local balance entirely and not be able to service the forward

n minutes is hard to figure out a magic number for, maybe that could be adjustable as well? A surge of payments can happen lightning-fast. Another way to approach things is to use burst rate limiting, so that you can update a price quickly if necessary but then your update fidelity will decrease. If burst is allowed a network broadcast could happen much more quickly than ten minutes

a way to lower the risk of these things going against the market dynamics is just to make them optional that way the operators can choose what is working best for them

[yyforyongyu]

I think the 10 minutes period should be configurable.