close should force by default, increase timeout to 48 hours?

[rustyrussell]

Suggested by: @JavierRSobrino

The current behavior of returning, but still trying to close, it not very useful. It should probably, after a long default delay, do a unilateral close.

2 days is long enough to reconnect to anything likely to come back anytime soon, IMHO.

What do you think, @ZmnSCPxj ?

[JaviLib]

I can confirm this issue. External wallets like Spark Wallet use the normal close, so if you close an offline channel (which is the usual reason) it remains for ever in the state of awaiting connection with the default options. I opened a related issue in Spark Wallet here shesek/spark-wallet#97

[ZmnSCPxj]

Current force=True behavior is to unilaterally fail without even trying a mutual close. Maybe what we want is to have the timeout force a unilateral instead?

The issue is that if you wait 48 hours before initiating unilateral, you have to wait xx more blocks before you get funds.

Do we need more smarts? I would prefer keeping a dumb close (directclose?) that does just initiate a mutual/unilateral close, then have some smart close with timeouts and heuristics (default to a mutual close if connected, or wait and try connect if disconnected, then have some hour-long timeout to unilateral) in a porcelain builtin plugin.

[JaviLib]

I think it can be as simple is to force by default with a timeout of 48h, and inform the user that he has to wait for both the timeout to initiate the unilateral and for the blocks.
Also an option to remove the close operation if it hasn't be committed yet anytime in the waiting period.

[ZmnSCPxj]

I am uncertain what you imagine the close operation to be. "Force" means drop the channel unilaterally, meaning posting our unilateral close tx to the Bitcoin mempool. We cannot "remove" a close operation; once the peer has seen that the unilateral close tx has been broadcast and is now in its own mempool, it will presume that the close has been done and will no longer talk with us about the channel (i.e. it becomes unuseable already). Timeout means little if you drop unilaterally --- your real timeout is started when it gets confirmed onchain, and ends when the locktime indicated by your peer ends.

If you force by default, then there is no point to doing a timeout --- it will be closed, whether the peer is online or not (forced closes talk to the Bitcoin network, which is always online), and the real timeout is the locktime indicated by your peer.

Can you indicate to me exactly what you expect from this "force by default"? Do you mean a unilateral close? Mutual close? Wait for peer to come online and do mutual close if so but fall back to unilateral close after nn hours (and remember, if you do a unilateral close, the funds will be available only after a timeout that only starts at the time you initiate the unilateral close)?

[JaviLib]

Sorry if I didn't explain it correctly I meant: try to normal close for 48h, waiting for the other party to connect, and if the other party doesn't connect at the moment of timeout, then force a unilateral close automatically. I think this should be the default behavior because it is not very useful to have a channel for ever waiting; a channel that goes offline for more than 2 days, usually goes offline for ever. There is no point in waiting for ever.

Even further, there is a better version of this kind of close that makes a lot of sense to me: you can check how much time that channel has been already offline, and if we can be sure that it has already been offline for 48h before we solicit a close, just go into unilateral directly, no need for a timeout.

What I meant by letting the user to remove the close operation is only for the time that we are waiting for the other party to become online. Of course, once the other party has confirmed the close, or we have initiated the unilateral close, I don't expect to be able to remove that operation. I meant only while waiting for the other party. Anyway, this feature is probably less important than the other one.

[ZmnSCPxj]

Thank you. This is a massive change in the behavior of close, so there is risk of breaking some other software, and because you want a change in default behavior, that is likely to affect a lot of software currently using the defaults.

@rustyrussell it might be better to remove the force parameter to close and switch the current close command to something lower-level like directclose.

[JaviLib]

Please consider that this should have been the correct behavior from the beginning. I recommend informing the users and other dependent software about the change after releasing the updates. We are in early stages of development still, and we are on time to make changes to proper defaults. In the future it is only going to get harder. Thanks.