Enable setting fixed password for LND wallet

[Kixunil]

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

LND requires setting a wallet password during initialization. This is unfortunate, because in many scenarios, the password doesn't help. (It may be even a net negative! See below.)

Example: an external node with full disk encryption already protects against physical theft, the service is running under a separate user account, the backups are encrypted by some other means. Basically, the only case when it helps is an attacker having read permission to the wallet file and not having read (or write) permission to any other interesting file, including, but not limited to:

• Admin macaroon - stored on disk unencrypted, can be used to empty the wallet and send to an attacker.
• LND memory (/proc/mem)
• Temp files that might be used for backups
• Backup daemon memory

Especially, considering the fact that macaroons are often in the same directory as wallet, it's extremely unlikely that LND password can protect against meaningful attacks. Further, it comes with its own set of problems:

• The risk of loss by the user
• When LND crashes (which happens quite often), it's stuck. If the user doesn't unlock it soon enough, peers might cheat on LN contracts
• Unnecessary UX burden
• Additional logic in software to handle

Describe the solution you'd like
Have an option to set lnd_wallet_password in the config file or just a bool flag to set it to password would be harmful here or other fixed value (meaningful value like the suggested one clearly explains what's going on). If this option is set, the RTL UI doesn't require/allow setting the password during wallet creation and it uses the fixed one instead. If RTL encounters locked LND, it attempts to use that password to unlock it automatically. (This doesn't propose for RTL to be used as LND unlocker, the auto unlock is just a fallback.)

Describe alternatives you've considered
The obvious alternative is to remove the password from LND as discussed in issue at their repo. Sadly, they didn't even reply to the question asking if they would merge the PR. I suspect that there's a good change a PR would hang there for a very long time.

Additional context
There's already tons of always online node setups, often containing some sort of isolation or encryption, where the arguments above apply. This would be extremely helpful for my project too.

[saubyk]

This must be addressed at the implementation level. We do not want to weaken the security model assumed at the implementation level, by obfuscating it at the app level, to make the UX simpler.

[Kixunil]

Well, the security model is completely broken. 🤷 I agree that solving it at LND would be much better. Sadly they did not even reply a simple answer "Yes, we would/No, we wouldn't accept a PR."

So double thanks to you for at least replying, even if its no.