各種 Lightning 實現如何處理延遲？在使用不愉快的路徑之前，他們等待對等方提供簽名多長時間？
Rene Pickhardt 在這個關於在現有閃電通道中提供簽名或合作關閉閃電通道時使用嵌套（或“遞歸”）MuSig2 或 FROST 的答案中提出了閃電網路的延遲問題。
（一旦閃電協議支持 Schnorr 簽名，即使在通道開放時資助的通道交易對手之間的 2-of-2 多重簽名仍然是 2-of-2，也可以這樣做。）
BOLT 中未指定如何處理延遲。那麼目前各種 Lightning 實現如何處理延遲？在假設對等方沒有響應並使用不愉快的路徑之前，他們等待對等方提供簽名多長時間？如果在此案例中使用 MuSig2 或 FROST 協議（目前）生成有效簽名，這將給出一個上限。
這在閃電開發郵件列表中進行了討論。
克里斯蒂安·德克爾說：
這裡值得一提的是，LN 協議通常對延遲不是很敏感，根據我的經驗，可以輕鬆處理非常慢的簽名者（3-5 秒延遲）而不會引起太多問題，除了轉發速度較慢以防我們談論路由節點。我希望路由節點簽名者遠低於 1 秒標記，即使在實現更複雜的簽名者邏輯時，包括 MuSig2 或嵌套的 FROST。
特別要記住，LN 協議實現了批處理機制，將更改作為批處理應用於承諾事務。並非每項更改都需要承諾並因此需要簽名。這意味著雖然緩慢的簽名者可能會對支付延遲產生影響，但它通常不應該對路由節點的吞吐量產生影響。
這並不意味著路由器不應該爭取盡可能快，但我認為在考慮到我們所擁有的整體網路延遲時，通過本地鏈路執行的 MuSig 方案不太可能出現問題。對於邊緣節點來說，放寬時間是相當不錯的，因為它們可能處於緩慢或不穩定的連接上，但路由器是一個完全不同的類別。
馬特科拉洛補充說：
一般來說，特別是對於“邊緣節點”，是的，但是如果轉發節點開始花費整整一秒來轉發付款，我們可能需要開始積極避免任何此類節點 - 而我希望所有轉發節點都花費 30秒轉發以改善隱私，理想情況下，使用者希望支付在 100 毫秒內完成，中間有多次支付重試。
這顯然可能永遠不會在閃電網路中發生，但將 95% 的支付時間縮短到一秒可能是一個不錯的目標，這需要永遠不必重試支付，並且轉發節點的時間不超過 150 毫秒。
當然，我認為我們不應該在對等層級引入超時 - 如果您的對等點離開一秒鐘並且沒有快速響應頻道更新，則不值得關閉頻道，但我們最終會這樣做如果將來成為更多問題，則希望在路線選擇中進行處理。