huge amount of transactions verified on startup. lnwatcher naively recursing to depth 2

Recently one of my wallets started being very slow on startup, and LN channels were stuck for a long time in “OPENING” state (sometimes up to 30 minutes).

Looking through the logs I saw that Electrum was trying to verify lots of transactions (~ 10 thousand) that seemed completely unrelated to my wallet. I went digging for the cause, and here’s my step-by-step analysis of what happened:

1. LN channel was opened (example funding tx: https://www.blockchain.com/btc/tx/1e09be2190eddc2677e0d524441e60083f76c7ae6a0b0354d9ab7d70e938feeb)
2. After some time this LN channel was closed (commitment tx: https://www.blockchain.com/btc/tx/afce9e0ac1bb644b8da13ea075ef1830ce2cce132914951416521b7f63392963)
3. This channel was opened with NiceHash node, and it seems that they aggregate all income from closed channels onto a single address (here’s the transaction: https://www.blockchain.com/btc/tx/7b339381b3f69904bd2697941fa2f4646aeb4aa09921a2d8af37a954642ed27f, and here’s the address: https://www.blockchain.com/btc/address/bc1qtngut72y8mptjqq762y2thyflty8jc9te9eplp2cs73jnkfst0lqlaa909)
4. Now on startup Electrum attempts to check on-chain situation for the channels (method check_onchain_situation in lnwatcher.py), and inspects the funding transaction by calling inspect_tx_candidate.
5. inspect_tx_candidate recurses through all transaction outputs, up to 2 hops.
6. Unfortunately 2 hops is enough to reach the address that NiceHash uses to aggregate the funds (https://www.blockchain.com/btc/address/bc1qtngut72y8mptjqq762y2thyflty8jc9te9eplp2cs73jnkfst0lqlaa909).
7. This address is then added to the synchronizer, which in turn tries to download and verify the entire history of the address (in method _on_address_status).
8. Electrum proceeds to verify each and every transaction, and quickly runs into rate-limiting from the public server.

Do I understand correctly that Electrum adds these addresses to the watchlist in order to catch Revocable Delivery transactions (according to diagram in the LN paper)?

Maybe there is some way of avoiding recursing through addresses that are provably unrelated to current wallet, in order to reduce unnecessary load on public Electrum servers, and improve LN UX in Electrum?

Electrum version: git, 149cccbc4 (latest at this time)

[SomberNight]

BOLT-03 is the most up-to-date as that is the spec itself, however it might not be easy to understand without some high level understanding beforehand 😕 Try maybe tbast’s Lightning transactions: from Zero to Hero (snapshot)

[Rogach]

Thank you! Tested on my wallet - the problem is gone.