📅 Original date posted:2022-06-29
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> On 6/28/22 9:05 AM, Christian Decker wrote:
>> 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 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.
>
> Matt
Absolutely agreed, and I wasn't trying to say that latency is not a
concern, I was merely pointing out that the protocol as is, is very
latency-tolerant. 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.
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 13:06:16
in reply to nevent1q…gl5g
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 13:06:16Event JSON
{
"id": "0e1c20c880ea303c8aad7d437db4b0baf9d2e65295ebabc7760c82ebeadb9a4a",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315976,
"kind": 1,
"tags": [
[
"e",
"dc50ebb4a33ebb68559db83f1f909a9de4df76c851710dee0b49ae8b2ad5f61f",
"",
"root"
],
[
"e",
"a35558c0ecdb1a78722f1b923e8a14da4ec8f666312f0d9909a524de23997d38",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2022-06-29\n📝 Original message:\nMatt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\n\u003e On 6/28/22 9:05 AM, Christian Decker wrote:\n\u003e\u003e It is worth mentioning here that the LN protocol is generally not very\n\u003e\u003e latency sensitive, and from my experience can easily handle very slow\n\u003e\u003e signers (3-5 seconds delay) without causing too many issues, aside from\n\u003e\u003e slower forwards in case we are talking about a routing node. I'd expect\n\u003e\u003e routing node signers to be well below the 1 second mark, even when\n\u003e\u003e implementing more complex signer logic, including MuSig2 or nested\n\u003e\u003e FROST.\n\u003e\n\u003e In general, and especially for \"edge nodes\", yes, but if forwarding nodes start taking a full second \n\u003e to forward a payment, we probably need to start aggressively avoiding any such nodes - while I'd \n\u003e love for all forwarding nodes to take 30 seconds to forward to improve privacy, users ideally expect \n\u003e payments to complete in 100ms, with multiple payment retries in between.\n\u003e\n\u003e This obviously probably isn't ever going to happen in lightning, but getting 95th percentile \n\u003e payments down to one second is probably a good goal, something that requires never having to retry \n\u003e payments and also having forwarding nodes not take more than, say, 150ms.\n\u003e\n\u003e Of course I don't think we should ever introduce a timeout on the peer level - if your peer went \n\u003e away for a second and isn't responding quickly to channel updates it doesn't merit closing a \n\u003e channel, but its something we will eventually want to handle in route selection if it becomes more \n\u003e of an issue going forward.\n\u003e\n\u003e Matt\n\nAbsolutely agreed, and I wasn't trying to say that latency is not a\nconcern, I was merely pointing out that the protocol as is, is very\nlatency-tolerant. That doesn't mean that routers shouldn't strive to be\nas fast as possible, but I think the MuSig schemes, executed over local\nlinks, is unlikely to be problematic when considering overall network\nlatency that we have anyway.\n\nFor edge nodes it's rather nice to have relaxed timings, given that they\nmight be on slow or flaky connections, but routers are a completely\ndifferent category.\n\nChristian",
"sig": "594b1faf66cf0b3a5bfe02fe60b9e01b81affa44f6155dfefd71c09342f0aef24f2bcb92c9a0894bdd841d7c5a5a8eb624593635d964f6778692323223dded7c"
}