How can I speed up payments to my c-lightning server?

Question

I setup a BTCPayServer on an AWS instance with a pruned bitcoind and c-lightning. I setup an inbound channel from Bitrefill and everything does work but I'm disappointed about the performance.

Using a Phoenix wallet it consistently takes 16s for payments to get confirmed while another BTCPayServer a friend configured and runs at home on his RPi which I don't have a direct channel to neither takes 8s.

The transaction details tell a slightly different story. According to those, paying my server took 11, 4, 4 and 4s while paying the other server took 5s. I assume that is measuring time only after some costly hand-shaking and routing but the time between hitting "pay" and the website and my phone displaying simultaneously "success" is much longer. Can I decrease that time somehow? Would I need more inbound channels, so my phone finds a faster one? Is there some option to speed things up? Is dual core the issue? ...

Answer 1

1. Lightning needs very little computing resources so the hardware in use is most certainly not the issue and has very little impact at all.
2. The described difference in time between the sending and receiving node is normal, to be expected and cannot be changed. The reason is that the payment/routing process works by selecting a path along which HTLCs are tried to be set up to the recipient. As soon as all HTLCs are set up, the money has arrived from the recipients point of view. However, from the sender's point of view all the HTLCs need to be settled. Setting up an HTLC and settling it takes about the same time within a single channel. Thus in the case that a path with enough liquidity was used the payment is finished in half the time for the recipient as for the sender.
3. Setting up and settling HTLCs is mainly bounded by a cryptographic handshake that needs 5 messages to be sent over the wire between the two peers. Thus, the wall lock time of a payment on a path with enough liquidity will be faster if it includes fewer channels and if the peers in every hop are network-topographically close, which might yield a potential for optimization. As a rule of thumb, you can assume 100 ms for a single message and since a round-trip takes 10 messages you can expect roughly 1 seconds per included channel from a sender's point of view.
4. The above mentioned things assumed a path with enough liquidity. However as described in this paper the balance values are unknown so we have a random process. Currently, nodes try to find the cheapest path. The paper suggests that you can reduce the number of attempts significantly by trying the most likely paths (roughly those that are short and have more capacity).

Overall yes, your position in the network with respect to topology and the method for selecting paths makes a difference and might be used for performance tweaking. As nodes have not implemented probabilistic path-finding yet, this would require custom code. It might even make sense to keep the same number of attempts and instead prefer geographically shorter links though I would focus on selecting paths that minimize the expected number of attempts.