📅 Original date posted:2022-06-28
📝 Original message:
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
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 13:06:16
in reply to nevent1q…ys0l
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 13:06:16Event JSON
{
"id": "55fac1a2ec3e864e57def357388bdf281215de73937c6c17014f31e87fbd2735",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686315976,
"kind": 1,
"tags": [
[
"e",
"dc50ebb4a33ebb68559db83f1f909a9de4df76c851710dee0b49ae8b2ad5f61f",
"",
"root"
],
[
"e",
"83cda8f5c5754ec6ddbe70d6feadeb4315cca06c8649dda400bd683e6d9a1fe9",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2022-06-28\n📝 Original message:\nOn 6/28/22 9:05 AM, Christian Decker wrote:\n\u003e It is worth mentioning here that the LN protocol is generally not very\n\u003e latency sensitive, and from my experience can easily handle very slow\n\u003e signers (3-5 seconds delay) without causing too many issues, aside from\n\u003e slower forwards in case we are talking about a routing node. I'd expect\n\u003e routing node signers to be well below the 1 second mark, even when\n\u003e implementing more complex signer logic, including MuSig2 or nested\n\u003e FROST.\n\nIn general, and especially for \"edge nodes\", yes, but if forwarding nodes start taking a full second \nto forward a payment, we probably need to start aggressively avoiding any such nodes - while I'd \nlove for all forwarding nodes to take 30 seconds to forward to improve privacy, users ideally expect \npayments to complete in 100ms, with multiple payment retries in between.\n\nThis obviously probably isn't ever going to happen in lightning, but getting 95th percentile \npayments down to one second is probably a good goal, something that requires never having to retry \npayments and also having forwarding nodes not take more than, say, 150ms.\n\nOf course I don't think we should ever introduce a timeout on the peer level - if your peer went \naway for a second and isn't responding quickly to channel updates it doesn't merit closing a \nchannel, but its something we will eventually want to handle in route selection if it becomes more \nof an issue going forward.\n\nMatt",
"sig": "3100015ef4b6277deff101a7fa77916e8b024d00bde58793571858fede5c42791aec8957f294f91aa1a9db7b4b323a9e9f3da3ab2072d750ed902a8e61cadcfe"
}