Is it possible to be more considerate towards LOOP peers that do regular loop-ins to fill up the channel? I think it is already being done but recently my channel was still closed even though I loop-in frequently and never let the channel drain or even let it come close to being empty.
If there is a high chance of the channel balance being restored with a loop-in, then I think it is beneficial to all parties (LOOP, the peer and the LOOP users) that the channel stays operational by reducing downtime of the channel as much as possible.
The timing of this request is relevant because workarounds that work now will not anymore in the future when coop-close will work with pending htlc's.
Perhaps as a suggestion: to check if the possibility of a loop-in is likely, it is not only possible to look at what has happened in the past but perhaps also if there are currently loop-in htlc's published. That way a peer can signal their intention to perform a loop-in. Combining the two could give a strong prediction.
Is it possible to be more considerate towards LOOP peers that do regular loop-ins to fill up the channel? I think it is already being done but recently my channel was still closed even though I loop-in frequently and never let the channel drain or even let it come close to being empty.
If there is a high chance of the channel balance being restored with a loop-in, then I think it is beneficial to all parties (LOOP, the peer and the LOOP users) that the channel stays operational by reducing downtime of the channel as much as possible.
The timing of this request is relevant because workarounds that work now will not anymore in the future when coop-close will work with pending htlc's.
Perhaps as a suggestion: to check if the possibility of a loop-in is likely, it is not only possible to look at what has happened in the past but perhaps also if there are currently loop-in htlc's published. That way a peer can signal their intention to perform a loop-in. Combining the two could give a strong prediction.