<p>This was discussed on the lightning-dev mailing list.</p>
<p>Christian Decker <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003619.html" rel="nofollow noreferrer">stated</a>:</p>
<blockquote>
<p>It is worth mentioning here that the LN protocol is generally not very
latency sensitive, and from my experience can easily handle very slow
signers (3-5 seconds delay) without causing too many issues, aside from
slower forwards in case we are talking about a routing node. I'd expect
routing node signers to be well below the 1 second mark, even when
implementing more complex signer logic, including MuSig2 or nested
FROST.</p>
<p>In particular remember that the LN protocol implements a batch
mechanism, with changes applied to the commitment transaction as a
batch. Not every change requires a commitment and thus a signature. This
means that while a slow signer may have an impact on payment latency, it
should generally not have an impact on throughput on the routing nodes.</p>
</blockquote>
<blockquote>
<p>That doesn't mean that routers shouldn't strive to be
as fast as possible, but I think the MuSig schemes, executed over local links, is unlikely to be problematic when considering overall network
latency that we have anyway. For edge nodes it's rather nice to have relaxed timings, given that they
might be on slow or flaky connections, but routers are a completely
different category.</p>
</blockquote>
<p>Matt Corallo <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003620.html" rel="nofollow noreferrer">added</a>:</p>
<blockquote>
<p>In general, and especially for &quot;edge nodes&quot;, yes, but if forwarding nodes start taking a full second
to forward a payment, we probably need to start aggressively avoiding any such nodes - while I'd
love for all forwarding nodes to take 30 seconds to forward to improve privacy, users ideally expect
payments to complete in 100ms, with multiple payment retries in between.</p>
<p>This obviously probably isn't ever going to happen in lightning, but getting 95th percentile
payments down to one second is probably a good goal, something that requires never having to retry
payments and also having forwarding nodes not take more than, say, 150ms.</p>
<p>Of course I don't think we should ever introduce a timeout on the peer level - if your peer went
away for a second and isn't responding quickly to channel updates it doesn't merit closing a
channel, but its something we will eventually want to handle in route selection if it becomes more
of an issue going forward.</p>
</blockquote>

CC BY-SA 4.0
2022-06-30T11:33:43.253Z
2022-06-30T16:51:06.253Z
2022-06-30T16:51:06.253Z
Michael Folkson
<p>Rene Pickhardt brought up the problem of latency on the Lightning Network in this <a href="https://bitcoin.stackexchange.com/questions/114112/can-you-do-p2wsh-p2sh-on-lightning-network-ln">answer</a> on using nested (or &quot;<a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003600.html" rel="nofollow noreferrer">recursive</a>&quot;) MuSig2 or FROST when providing a signature within an existing Lightning channel or to cooperatively close a Lightning channel.</p>
<p>(This could be done once the Lightning protocol supports Schnorr signatures even if the 2-of-2 multisig between the channel counterparties that is funded at the opening of the channel remained 2-of-2.)</p>
<p>How to treat latency isn't spec'ed in the BOLTs. So how do the various Lightning implementations currently treat latency? How long do they wait for a peer to provide a signature before assuming the peer is unresponsive and instead using an unhappy path? This would give an upper limit on how long the MuSig2 or FROST protocol could (currently) take to generate a valid signature if they were used in this use case.</p>

<lightning-network><latency><musig><frost>
How do the various Lightning implementations treat latency? How long do they wait for a peer to provide a signature before using unhappy path?
Michael Folkson
# How do the various Lightning implementations treat latency? How long do they wait for a peer to provide a signature before using unhappy path?

(Asked by: username_0 on 2022-06-20)

Rene Pickhardt brought up the problem of latency on the Lightning Network in this [answer](https://bitcoin.stackexchange.com/questions/114112/can-you-do-p2wsh-p2sh-on-lightning-network-ln) on using nested (or "[recursive](https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003600.html)") MuSig2 or FROST when providing a signature within an existing Lightning channel or to cooperatively close a Lightning channel.

(This could be done once the Lightning protocol supports Schnorr signatures even if the 2-of-2 multisig between the channel counterparties that is funded at the opening of the channel remained 2-of-2.)

How to treat latency isn't spec'ed in the BOLTs. So how do the various Lightning implementations currently treat latency? How long do they wait for a peer to provide a signature before assuming the peer is unresponsive and instead using an unhappy path? This would give an upper limit on how long the MuSig2 or FROST protocol could (currently) take to generate a valid signature if they were used in this use case.

**Tags:** lightning-network, latency, musig, frost


---

## 1 answers

### Answer by username_0 on 2022-06-30. Score: 1 | Accepted answer

This was discussed on the lightning-dev mailing list.

Christian Decker [stated](https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003619.html):

> It is worth mentioning here that the LN protocol is generally not very
> latency sensitive, and from my experience can easily handle very slow
> signers (3-5 seconds delay) without causing too many issues, aside from
> slower forwards in case we are talking about a routing node. I'd expect
> routing node signers to be well below the 1 second mark, even when
> implementing more complex signer logic, including MuSig2 or nested
> FROST.
>
> In particular remember that the LN protocol implements a batch
> mechanism, with changes applied to the commitment transaction as a
> batch. Not every change requires a commitment and thus a signature. This
> means that while a slow signer may have an impact on payment latency, it
> should generally not have an impact on throughput on the routing nodes.

> That doesn't mean that routers shouldn't strive to be
> as fast as possible, but I think the MuSig schemes, executed over local links, is unlikely to be problematic when considering overall network
> latency that we have anyway. For edge nodes it's rather nice to have relaxed timings, given that they
> might be on slow or flaky connections, but routers are a completely
> different category.

Matt Corallo [added](https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003620.html):

> In general, and especially for "edge nodes", yes, but if forwarding nodes start taking a full second
> to forward a payment, we probably need to start aggressively avoiding any such nodes - while I'd
> love for all forwarding nodes to take 30 seconds to forward to improve privacy, users ideally expect
> payments to complete in 100ms, with multiple payment retries in between.
>
> This obviously probably isn't ever going to happen in lightning, but getting 95th percentile
> payments down to one second is probably a good goal, something that requires never having to retry
> payments and also having forwarding nodes not take more than, say, 150ms.
>
> Of course I don't think we should ever introduce a timeout on the peer level - if your peer went
> away for a second and isn't responding quickly to channel updates it doesn't merit closing a
> channel, but its something we will eventually want to handle in route selection if it becomes more
> of an issue going forward.


---

