Unintended behaviour with lowToHighRoutingPlugin due to outlier LOOP peer with high fee

[silenzara]

To prepare lnd for looping out the mc is manipulated to help with finding a route to LOOP. This is done by building a list of LOOP peers and sorting that list by fee.

Before each "attempt" (defined by MaxPaymentRetries which is 3 by default) the lowToHighRoutingPlugin.BeforePayment is called which will reconfigure the mc based on the sorted-by-fee list of LOOP peers.

The list is simply divided by MaxPaymentRetries and with each attempt that is >1 the fee floor is increased and each peers with fees below that floor will essentially be excluded from the pathfinding.

The fee range to LOOP right now is 180-14,262 sats, this will result in floor steps of (14262-180)/3 = 4694 sats (first attempt does not count so the floor for attempt#1 is 180). Part of the relevant code:

        // Do not do anything unless we tried to route the payment at least
	// once.
	if currAttempt < 2 {
		return nil
	}

	// Calculate the limit until we'll disable edges. The way we calculate
	// this limit is that we take the minimum and maximum fee peers which
	// define our fee range. Within this fee range we'll scale linearly
	// where each step euqals to the range divided by maxAttempts.
	minFee := r.nodesByMaxFee[0].fee
	maxFee := r.nodesByMaxFee[len(r.nodesByMaxFee)-1].fee
	limit := minFee +
		((maxFee-minFee)/int64(maxAttempts))*int64(currAttempt)

https://github.com/lightninglabs/loop/blob/master/routing_plugin.go#L509

Effective, the peers that are included for pathfinding by this logic per attempt:

Attempt 1: fee >=180-14262
Attempt 2: fee >=9568-14262 (the double step up is another issue)
Attempt 3: fee >=14262-14262

In practice, only the first attempt will be able to find a "reasonable" route to LOOP since that's the only one that uses a floor that actually includes pretty much all the peers.

What I have not mentioned yet is that if you look at the LOOP peers all of them have LOOP fees <= 4000 ppm (I disregard base fee for since it's not relevant in this issue) except for one that has 14,262 ppm. This is causing the big steps.

So this lowToHighRoutingPlugin mechanism does not seem to do anything useful in practice. It also does not seem to hinder the ability to find a path to LOOP since there are plenty of peers in the first attempt.

Though, more broadly speaking now I understand this code better: conceptually, this whole approach is not intuitive to me. To me it seems like a better strategy to step up the fee ceiling and slowly include more peers with higher fees instead of excluding peers with lower fees. It might take a bit longer to find a path but the fees could be lower for the client. It also does not completely exclude low fee LOOP peers that could be used for a partial payment via MPP.

Full disclosure: I am a LOOP peer that has a relatively low fee compared to other peers so changes to this code could have an impact on my ability to route to LOOP.