You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The currently proposed MIN_HTLC_RELAY_HOLDING_CELL_MILLIS = 100 is quite high for a lower-bound on the forwarding delay, as is delaying HTLC forwarding up to 500ms.
As the proposed values are pretty conservative and they seem to discourage users from applying any forwarding delay at all, we should revisit them. Proposing a forwarding delay to cover 1-2 RTTs around the node should likely be sufficient, especially if multiple nodes per path apply it. To this end, drawing from a (preferably log-normal) distribution from something in [50,250] would likely suffice.
The text was updated successfully, but these errors were encountered:
Makes sense. If we do this we should probably just do the random draw for the user. Tho if we want to get fancy we probably want to just do bulk forwards on a fixed timer unrelated to when we receive HTLCs, eg every 100ms.
The currently proposed
MIN_HTLC_RELAY_HOLDING_CELL_MILLIS = 100
is quite high for a lower-bound on the forwarding delay, as is delaying HTLC forwarding up to 500ms.As the proposed values are pretty conservative and they seem to discourage users from applying any forwarding delay at all, we should revisit them. Proposing a forwarding delay to cover 1-2 RTTs around the node should likely be sufficient, especially if multiple nodes per path apply it. To this end, drawing from a (preferably log-normal) distribution from something in
[50,250]
would likely suffice.The text was updated successfully, but these errors were encountered: