[feature]: allow configuring upfront shutdown address in `lnd.conf`

[yyforyongyu]

As of today, a funder can easily specify the upfront shutdown address via openchannel. A fundee, however, needs to set up a channel acceptor to specify a custom address. This can be cumbersome, especially in the case where a remote signer is used for a hot-cold wallet setup. We could instead config this shutdown address in lnd.conf,

• add a new config value upfront-shutdown-address and use it when opening and accepting channels.
• it can be overwritten by the value specified in openchannel and/or channel acceptor.

Going with this approach does decrease the level of privacy as all the funds now go to the same cold wallet address. A better approach is to stick to the current setup - always derive a new cold wallet address when opening or accepting a channel, however this is up to the user to decide.

[blckbx]

Going with this approach does decrease the level of privacy as all the funds now go to the same cold wallet address. A better approach is to stick to the current setup - always derive a new cold wallet address when opening or accepting a channel, however this is up to the user to decide.

As a middle way, could we provide an array of addresses that are cycled through?
Are these addresses also used in force-closes?

[theedtron]

Can I jump on this?

[raehat]

@theedtron, if you're currently not working on this, can I take this?

[theedtron]

@raehat still planning to work on it.

[NishantBansal2003]

A fundee, however, needs to set up a channel acceptor to specify a custom address.

Hey @yyforyongyu,
I’ve been working on this issue and encountered some challenges. While specifying the shutdown address for the funder via the lnd.conf file works perfectly, I’ve noticed that specifying the shutdown address for the fundee (using RPCAcceptor) doesn’t work as intended—the funds still get transferred to the LND wallet instead of the specified BTC wallet.
To address this, I have some questions and would appreciate your insights:

1. I understand that adding the upfront-shutdown-address configuration in the lnd.conf file ensures that the funder doesn’t need to specify the close_address flag, and the remaining funds are automatically transferred to the specified on-chain address.

2. However, I’m unclear on how this process works for the fundee. How does the fundee currently specify a close address? Could you explain the procedure for setting a shutdown address when accepting an incoming channel request? (I believe understanding this will help me debug the issue and pinpoint the exact location for a fix.)

Can you also guide me on adding an itest when opening a channel for both the fundee and the funder?

Thanks in advance for your guidance!

[NishantBansal2003]

A fundee, however, needs to set up a channel acceptor to specify a custom address.

Hey @yyforyongyu, I’ve been working on this issue and encountered some challenges. While specifying the shutdown address for the funder via the lnd.conf file works perfectly, I’ve noticed that specifying the shutdown address for the fundee (using RPCAcceptor) doesn’t work as intended—the funds still get transferred to the LND wallet instead of the specified BTC wallet. To address this, I have some questions and would appreciate your insights:

1. I understand that adding the upfront-shutdown-address configuration in the lnd.conf file ensures that the funder doesn’t need to specify the close_address flag, and the remaining funds are automatically transferred to the specified on-chain address.
2. However, I’m unclear on how this process works for the fundee. How does the fundee currently specify a close address? Could you explain the procedure for setting a shutdown address when accepting an incoming channel request? (I believe understanding this will help me debug the issue and pinpoint the exact location for a fix.)

Can you also guide me on adding an itest when opening a channel for both the fundee and the funder?

Thanks in advance for your guidance!

Thanks! I was able to figure it out after spending more time exploring the codebase. @yyforyongyu, could you please take a look at PR #9432 whenever you have time?

[NishantBansal2003]

Hey @saubyk, could you please assign this issue to me for PR #9432 .
Thanks.