bLIP-51: Missing guidance on how the LSP should handle reorgs

[tnull]

Currently, bLIP-51 states:

In case the channel open failed

   - MUST set order_state to FAILED.
   - MUST issue a refund.

It is however not clear what constitutes a failed channel open, i.e., if reorgs/unconfirmations of the funding transaction count towards that.

In particular, imagine the following scenario: the client requests a 0-conf channel, the LSP opens the channel, the funding transaction confirms, but then a reorg happens and the funding transaction isn't confirmed anymore, possibly in violation of min_funding_confirms_within_blocks. I think in this case we should consider the channel open as failed and the LSP needs to refund the user to refund_onchain_address, I guess?

We should provide further guidance in the spec how to handle these cases.

Looking for feedback here to hear if we have ideas how to best address this.

(cc @MegalithicBTC @kaloudis)

[MegalithicBTC]

We don't really use refund_onchain_address. Maybe this is rare enough anyway that we would or could just provide refunds out-of-band.

[MegalithicBTC]

A more common occurrence that we HAVE seen is, we open a channel to client, but then the channel is force-closed by our node within a few minutes. We're still trying to understand why this happens but we're leaning toward the scenario where the user is running on very underpowered hardware, with very low RAM, and although his/her node can connect to our node, it can't keep up with the other requirements of the protocol -- like, when actually trying to send the messages back and forth that are required for keeping a channel open, the client node runs out of RAM.

This is very rare but we've now seen it in at least 2 instances -- and the hint that it's a resource-exhaustion problem is that we find that a client can reproduce this problem (and does often), by trying to open a second channel, which will again be closed by our node within a few minutes. We were also able to get system info from one user who was running on 15-year-old hardware with very little available RAM.