[feature]: Add ability to send force close and sweep balances to external wallet

[gkrizek]

Is your feature request related to a problem? Please describe.

When cooperatively closing a channel a user could supply a delivery_addr to send funds to an external wallet upon channel close. This can be set either when opening the channel or also when closing the channel. However, this only works for cooperatively closed channels. If the channel is force closed then the funds return to the LND internal onchain wallet.

Describe the solution you'd like

I would love to be able to send force close balances to a wallet outside of LND just like you can with cooperatively closed channels. I'm not clear on if this is possible, what the limitations are, or how hard this would be. However it would be great to operate an LND with the base minimum balances in the on-chain wallet at all times.

Describe alternatives you've considered

There really isn't a good alternative solution. A hack would be to write a script to check for funds that go into the onchain wallet and send them somewhere else, but that doesn't really solve to core issue.

[ellemouton]

Ok I did some light digging to see if this is actually possible without a spec change.

I think it is possible: Currently we derive all the base points from a single keyRing: https://github.com/lightningnetwork/lnd/blob/7a3101710c57f4c0ed0c73864b10ddd38e077217/lnwallet/wallet.go#L1316-L1345

But I think we can separate out these keyrings. We need the secrets for the revocation_basepoint, htlc_basepoint and multisig_basepoint on disk because we need to produce sigs for these throughout the lifecycle of the channel. But for the payment_basepoint (used to derive our output on the remote commitment tx) and the delayed_payment_basepoint (used to derive our output on the local commitment tx), I dont think we need to produce sigs for these during the operation of the channel.

From Bolt2:

Separating the `htlc_basepoint` from the `payment_basepoint` improves security: a node needs the secret associated with the `htlc_basepoint` to produce HTLC signatures for the protocol, but the secret for the `payment_basepoint` can be in cold storage.

[Roasbeef]

@ellemouton not sure that's what they're after, as if we (lnd) doesn't have the htlc_basepoint, then it can't sweep fully timed out HTLCs. Instead I think they want a way to give the sweeper an alternative way to obtain addresses to sweep into.

IMO, our current approach (always aggregrating and sweeping everything) ensures that once a channel has been force closed, then funds are protected under the central seed as soon as possible. If we stop doing that, then if the user is tasked with sweeping the funds (totally possible given the set of APIs and what you mention above), they may end up in a situation where an external bug or lack of data storage ends up leading to loss of funds.

[ellemouton]

Yeah @Roasbeef, I was just saying we could technically break out the payment basepoint and delayed payment basepoint. Ie, not the htlc basepoint.

But yeah, this only helps if a huge htlc is not in flux. But i assumed the main case for this is: no htlcs in flux and remote peer is just offline