Please add close_address setting for autopilot

[rbrooklyn]

Autopilot allows the user to "send and forget" funds to their LND installation, allowing LND to create new channels as it sees fit.

However, a "nice to have" feature would be to allow close_address usage, just as it works in openchannel. So the slightly more paranoid among us could set this to a wallet address not within LND's control.

For example, if something really strange is happening, such as an attack which results in force closing of channels, this allows us a chance to recover the funds to a known safe address, and prevent autopilot going nuts and spamming the network with new channels that might be constantly being closed due to the attack. This would allow the user to figure out why all of their 30 channels has just closed instead of their funds getting slowly taken away by on-chain fees with autopilot trying to fix the problem but actually making matters worse.

This would of course, add some frustration for users if they are manually closing channels which are misbehaving or suchlike and want to immediately re-use the funds. Therefore this should be optional. Even if this setting was enabled, the delivery_addr setting could be used to override this (assuming enable-upfront-shutdown was never set) if the user is controlling the closing of the channel themselves.

If an invalid address is configured, LND should refuse to start and give an error.

This feels like it would be an "easy" thing to add. But I admit my complete ignorance on that side of things. I'm not even sure if it's desirable, but it's something I felt I wanted with this installation, so for at least one person it's on the wishlist.

[carlaKC]

However, a "nice to have" feature would be to allow close_address usage, just as it works in openchannel. So the slightly more paranoid among us could set this to a wallet address not within LND's control.

The difference between OpenChannel and autopilot is that OpenChannel is initiated by a user, so they can easily provide an upfront shutdown address, whereas autopilot runs in the background and does not interact with the user (so there is no opportunity to provide an address).

Updating autopilot created channels to close out to addresses controlled by lnd is simple enough, we could just do so if the --enable-upfront-shutdown flag is set. However, closing out to a user provided address is a more complex matter, because of the question of interactivity. Options for this feature would be:

1. Provide a set of addresses on startup which autopilot will close out to; the issue here would be that you don't know how many addresses to provide, and what to do when autopilot runs out (address reuse isn't an option because it's a privacy leak)
2. Add a AddressGenerator interface which allows lnd to query an external source for an address for autopilot to use

[rbrooklyn]

Actually option 1 to a single was in my mind when I raised this issue. The priority in my mind is that my funds are safe. I'll deal with the privacy issues later, as long as I can control the keys and any attack is stopped then I don't care.

Although I accept for others this wouldn't be acceptable.

When you say "external source" in option 2... Could that be a public master key which Electrum can provide, (I guess other wallets also have this). LND would be able to be smart enough to go to the first unused one and use that as the close address from the outset?

Only issue I see with that is that I might go and use that address at some point in the future and LND has already chosen it and not used it yet, and if --enable-upfront-shutdown is set the user would be SOL from a privacy standpoint. Although that's the user's choice and education on the matter I think.

[carlaKC]

When you say "external source" in option 2

This probably wouldn't just be a pubkey, for the reasons you mention about still risking address reuse. It would be a specialized rpc endpoint (eg, GetFreshAddress) which queries your wallet for an unused address, which the wallet can then mark as used its side, to prevent reuse. If you go and manually select that address from a set of already used addresses, there's not much that can be done; down to choice/education as you say.

As an aside, I think it's worth touching on the security model of upfront_shutdown, because it's important to be aware of the level of security this option actually offers.

If you have a channel open with a peer that supports the feature, and you set an upfront address, your peer will make sure that cooperative closes of that channel are paid out to that address. If an attacker tries to close out to a different address, a behaving peer will disconnect and refuse to cooperatively close. There is also the possibility of the attacker colluding with your peer, and getting them to run a non-compliant node which allows the attacker to cooperative close out to a different address; possible but not probable, I'd say.

However, the attacker can still force close the channel, and the funds will not be paid out to that address, they will return to a seed-controlled address. The ease of attack is decreased, because they need to wait for the to_self_delay to elapse before they can clear the funds out, so need to control your node for a longer period of time, but it is still possible. Upfront shutdown is a best effort attempt to make these kinds of attacks more difficult, but it definitely doesn't prevent them all together.

[rbrooklyn]

It seems I still have some learning to do.

My thought behind upfront_shutdown was that the signed transactions between the nodes would only have the funds paid out to close_address in all situations. As the transactions are signed by both peers, I figured that the closing address would be enforced with these settings and that even if I was connected to an evil node, the best it could do is transmit an older state, which would still push the funds to the close_address address and therefore take my funds away from LND and to safety.

I guess I'm misunderstanding something.

I would still like to have some kind of safety feature whereby my funds are snatched away from LND (but into an address I can control) in all close channel circumstances, even if that means more inconvenience to myself.

A nice to have for those of us always dreading the worst, but still wanting to be reckless on lightning.

[yyforyongyu]

A trivial solution is to add a user specified close address when configuring the autopilot, but that would be a privacy disaster. A better solution might be enabling the autopilot to manage an xpub that's derived from your cold wallet. lnd can then use the addresses derived from that key as the shutdown address. Then, at least within lnd, we can ensure the addresses won't be reused.

[saubyk]

closing this as inconclusive on the solution and the need