Description
Looking at:
lnd/routing/payment_session.go
Line 221 in 19006b1
I see that currently the payment session route planner splits the amount into half if it was too large. While from a CS perspective I find this strategy very reasonable I believe there might be more things to consider.
As discussed with ZmnSCPxj on the Lightning dev mailinglist at: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002418.html there is the chance to use the necessity of splitting a payment to also rebalance ones own channels in order to be better equipped in future to fulfill payment requests. In that post I have referenced a small standalone python code
The main code that splits a payment amount according to ones own channels in an statistically optimal (meaning to provide best locally balanced channels) way boils down to these few lines of code which are easily implemented in go and in LND. Sorry for the weired variable naming - which follows main
# amount that is to be paid.
a = 0.7
# initial balance of channels
b = [0.1*i for i in range(10, 0, -1)]
if (a > sum(b)):
print("not enough funds to conduct such a payment")
exit()
new_funds = sum(b) - a
# assuming all channels have capacity of 1 btc
cap = len(b)
nu = float(new_funds) / cap
ris = [1*(float(x)/1 - nu) for x in b]
real_ris = [x for x in ris if x > 0]
s = sum(real_ris)
payments = [a*x/s for x in real_ris]
A strategy could be that if a payment won't go through instead of splitting by two one could use this initial strategy to select amounts and local channels which should be used for those amounts.
I have not simulated the effects of my strategy and did not compare them with your behaviour. However keeping the results of the original research in mind I am confident that the splitting strategy that I propose would result in overall lower routing failure rates on the lightning network.