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
At times I have several nodes that fail to connect because an agreement of the unilateral closing fee cannot be reached.
The error is visible in the logs with entries of the type:
INFO <remode_node_id>-chan#<sequence_nr>: Peer transient failure in CHANNELD_NORMAL: channeld WARNING: warning channel <channel_id>: update_fee x outside range a-b (currently y)
where x < a. Often x < y, but this doesn't matter.
The log entries appear on connect attempts, which may be either manual or recurring retries.
I realized that in my particular case this means that my node is suggesting a fee that is lower than what the peer can accept. I've seen that, if I call feerates perkw, it says that unilateral_close equals x. However, I have also observed cases where unilateral_close >> x, but I guess this means that there is some lag between the current estimates and what is proposed on connection.
I think that it might make sense to introduce some user configuration here together with detection of what the remote peer's bounds are, so that one can set leniency in accordance to one's risk assessment. I for one would accept a higher fee, but might be averse to fees that risk my funds getting stuck on closure. Others might make different judgements.
Issue and Steps to Reproduce
At times I have several nodes that fail to connect because an agreement of the unilateral closing fee cannot be reached.
The error is visible in the logs with entries of the type:
where
x < a
. Oftenx < y
, but this doesn't matter.The log entries appear on connect attempts, which may be either manual or recurring retries.
I realized that in my particular case this means that my node is suggesting a fee that is lower than what the peer can accept. I've seen that, if I call
feerates perkw
, it says thatunilateral_close
equalsx
. However, I have also observed cases whereunilateral_close >> x
, but I guess this means that there is some lag between the current estimates and what is proposed on connection.I think that it might make sense to introduce some user configuration here together with detection of what the remote peer's bounds are, so that one can set leniency in accordance to one's risk assessment. I for one would accept a higher fee, but might be averse to fees that risk my funds getting stuck on closure. Others might make different judgements.
getinfo
outputThe text was updated successfully, but these errors were encountered: