<ol>
<li>Lightning needs very little computing resources so the hardware in use is most certainly not the issue and has very little impact at all.</li>
<li>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 <strong>in the case that a path with enough liquidity was used</strong> the payment is finished in half the time for the recipient as for the sender.</li>
<li>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.</li>
<li>The above mentioned things assumed a path with enough liquidity. However as described in <a href="https://arxiv.org/abs/2103.08576" rel="nofollow noreferrer">this paper</a> 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).</li>
</ol>
<p>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.</p>

CC BY-SA 4.0
2021-05-18T19:25:37.063Z
Thank you! So 16s is kind of expected for longer, more international routes? I suppose on the receiving end I don't get any information on the route and my sending wallet - Phoenix - gives me no information on the route neither. So to generally speed things up I should get more diverse inbound channels for my receiving server and I can hope for the network generally to improve but the server itself is probably fine?
Giszmo
CC BY-SA 4.0
2021-05-18T22:48:43.463Z
Channels can actually be on nodes which use TOR to communicate with their partners. In those cases the network roundtrips might be even slower than the 100ms but I would say for a small node depending on where in the network it is located it can easily happen that your payment time is more than 10 seconds
Rene Pickhardt
CC BY-SA 4.0
2021-05-19T19:31:34.973Z
Hey Rene, I tried to interpret what the last sentence was trying to express. Could you please check whether I got your meaning right?
Murch
CC BY-SA 4.0
2021-05-18T07:35:35.107Z
2021-05-19T19:30:01.420Z
2021-05-19T19:30:01.420Z
Rene Pickhardt
<p>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.</p>
<p>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.</p>
<p>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 &quot;pay&quot; and the website and my phone displaying simultaneously &quot;success&quot; 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? ...</p>

<lightning-network><core-lightning><btcpay>
How can I speed up payments to my c-lightning server?
Giszmo
# How can I speed up payments to my c-lightning server?

(Asked by: username_0 on 2021-05-18)

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? ...

**Tags:** lightning-network, core-lightning, btcpay


---

## 1 answers

### Answer by username_1 on 2021-05-18. Score: 2

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](https://arxiv.org/abs/2103.08576) 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.

> **Comments:**
> **username_0**: Thank you! So 16s is kind of expected for longer, more international routes? I suppose on the receiving end I don't get any information on the route and my sending wallet - Phoenix - gives me no information on the route neither. So to generally speed things up I should get more diverse inbound channels for my receiving server and I can hope for the network generally to improve but the server itself is probably fine?  
> **username_1**: Channels can actually be on nodes which use TOR to communicate with their partners. In those cases the network roundtrips might be even slower than the 100ms but I would say for a small node depending on where in the network it is located it can easily happen that your payment time is more than 10 seconds  
> **username_2**: Hey username_1, I tried to interpret what the last sentence was trying to express. Could you please check whether I got your meaning right?  

---

