As long as your web browser is up to date, the risk of malware entering your system just by clicking on a link is relatively low. But if you want to further minimize the risk, you can disable JavaScript in your browser. However, this will limit the functionality of many websites. And if you are really paranoid you can run your web browser in a virtual machine.

Also you should not store your bitcoin savings on a computer connected to the internet. Preferably store them on a hardware wallet.

Wallets do not send the xpub directly to the Electrum server. Instead, they derive the addresses (--> script hashes) from the xpub and then request the balance for each individual address.

Alternatively you could try Strike's fee estimator: https://bitcoinchainfees.strike.me/v1/fee-estimates

LND does not allow multiple fee urls as of this point so the best alternative would still be to run your own Bitcoin node.

LND has actually had support for leader election for at least 3 years already. Some documentation on it can be found here: https://docs.lightning.engineering/lightning-network-tools/lnd/leader_election

But during my testing I did manage to get two nodes to become active at the same time, which is bad. I described it in this issue: https://github.com/lightningnetwork/lnd/issues/8913

This was an LND bug, where it would not resign from its leader role. etcd was working as it should.

Two weeks later the bug got fixed with this pull request: https://github.com/lightningnetwork/lnd/pull/8938

With the patch applied, healthcheck.leader.interval set to 60 seconds and cluster.leader-session-ttl set to 100 seconds, I could no longer produce a situation where multiple nodes were active at the same time.

With this configuration, each lnd node creates an etcd lease with a time-to-live of 100 seconds. This lease is kept alive at intervals of one third of the initial time-to-live. So in this case it is kept alive every 33 seconds. When a node loses its connection to the rest of the cluster, it takes 27-60 seconds to initiate a shutdown. And it takes 66-100 seconds for another node to take over. So in this configuration there is no room for overlap, so no chance of two nodes being active at the same time.

I did consider trying with bbolt on top of Ceph, but since etcd is already implemented in lnd it seemed like the more native approach to use etcd. But I am planning to compare this to a setup with Ceph and do some benchmarks.

I'm not sure I understand why polling would be a better option than LND being notified via ZMQ. Also there is only ever one instance of LND (the leader) connected to the Bitcoin node at the same time.

ZFS is designed to only run on a single server. So if that server fails, the node will be down. If we are trying to achieve high availability, we need a distributed system where ideally every server has its own uninterrupted power supply.

I explain the setup in more detail in the linked guide.

I haven't compared this to postgres yet, but sending a 1000-part payment to a channel partner on etcd slowed the node to a crawl.

I plan to do some benchmarks under different configurations and also compare it to a postgres backend. I also plan to benchmark lnd with a bbolt database running on a 3-node Ceph RBD.