option to skip OUR_DELAYED_RETURN_TO_WALLET

[gallizoltan]

Feature request: I'd like to see an option to skip the OUR_DELAYED_RETURN_TO_WALLET transaction.

Description: unilateral channel closure usually consist of two on-chain transactions:

1. the commitment transaction,
2. after some blocks (to give time for a potential penalty transaction) there comes a delayed return to the wallet.

Unilateral closures are sometimes inevitable. For example my counterparty went offline a year ago, and I'd like to get my liquidity back. Or some permanent error happens in the connection (bad reestablish revocation_number: {X} vs {Y}).

The first "commitment transaction" is expensive as hell, but inevitable. On the other hand, the second "delayed return" transaction is expensive too, but it could be avoided, I think. If I know for sure there will be no penalty transaction, then I'd like to skip the second tx, at my very own risk of course.

So, please give me an option to skip the second transaction, and consider the delayed output as spendable without the "delayed return".

[whitslack]

Agreed! I have never understood the need for sweeping the delayed output into a P2WPKH address if it is known that no newer channel state exists than that with which the channel was unilaterally closed (and so no justice transaction can ever claim the funds) — and if that isn't known, then the node should not be risking a unilateral closure in the first place, so I think we can say that anytime a node initiates a unilateral closure, it is reasonable to assume that no newer channel state exists. Under such assumption, why then does the delayed output of the unilateral closure need to be swept at all? Couldn't we simply place that output in the wallet to allow it to be spent in due course of node operations (i.e., for an explicit withdrawal or future channel opening)?

[ZmnSCPxj]

I have never understood the need for sweeping the delayed output into a P2WPKH address

If you are not using option_static_remotekey, then the delayed output cannot be recovered from an old db state and your hsm_secret. Even with option_static_remotekey the delayed output cannot be recovered if the old db state is so old as to predate the channel (though there may be ways to recover it still).

By sweeping immediately to a "plain" P2WPKH the money can be recovered onchain using only the hsm_secret even with loss of all db and all db backups.

So the option certainly could be added but people need to first ensure they have backups, like making the option --skip-delayed-return-to-wallet=yesIhavebackups

[ZmnSCPxj]

Just to be clear, this is not a simple change; it would require changes at hsmd level so it will sign non-plain-P2WPKH spends as well. Then some changes over in wallet/ so that it stores UTXOs that are not P2WPKH/P2SH-P2WPKH as well too. We do need to start coding for P2TR at some point. Finally, we need to figure out as well how to figure out how to detect the funds in a recovery situation with an incomplete db or something.

[gallizoltan]

@ZmnSCPxj, I understand it's not a simple change. Anyway, could somebody please implement it?
@cdecker, @rustyrussell, @m-schmoock, anybody please?
I mean it is really not funny, if one of my channels gets closed (not intentionally, but for some technical reasons), and I pay an extra 150 Sat/vB transaction for sending funds between my own addresses. 😞

[gallizoltan]

OUR_DELAYED_RETURN_TO_WALLET transaction with 200+ Sat/vB fee. Not a pretty sight. 😞 https://blockstream.info/tx/c65076007ededa5581b1d165efcf05e8fc6b160c224cbf2f783b2e5a98d2433f