[bug]: lncli getinfo uris spammed by 77 pubkey@tor.onion entries #10328
Description
Pre-Submission Checklist
- I have searched the existing issues and believe this is a new bug.
- I am not asking a question about how to use lnd, but reporting a bug (otherwise open a discussion).
LND Version
0.19.3-beta commit=v0.19.3-beta
LND Configuration
lnd.conf [Tor] Settings:
[tor]
tor.active=true
tor.v3=true
tor.skip-proxy-for-clearnet-targets=true
tor.streamisolation=false
healthcheck.torconnection.attempts=3
healthcheck.torconnection.timeout=10s
healthcheck.torconnection.backoff=30s
healthcheck.torconnection.interval=1m
Tor is running as systemd, and doesn't indicate rapid restarting. It was in fact Active for 3+Months.
Backend Version
BTC Core v29.0
Backend Configuration
Nothing specific for Tor / LND to be found here
OS/Distribution
Linux debian-nuc 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux
Bug Details & Steps to Reproduce
2nd time in 2 weeks, I see my lncli getinfo getting spammed by duplicate Tor addresses, and like to get to the root cause. I rarely had this with earlier version of LND (eg once or twice per year), and didn't change anything on the Tor settings (further below) since then.
Situation
lncli getinfo | jq -r '.uris[]' | sort | uniq -c
1 037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@207.154.241.207:9735
77 037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
lncli getinfo | jq -r '.uris[]'
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@207.154.241.207:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
037f66e84e38fc2787d578599dfe1fcb7b71f9de4fb1e453c5ab85c05f5ce8c2e3@s7zosuczrbmsc5jt75bj4ip6tvgjiwte4m5daowndge6hr4qyxdomgid.onion:9735
.....
Causing my LNDg dashboard to look like this (need 2.5 scrolls before content)
Expected Behavior
It would be good to understand where the issue is coming from, so I'm happy to adjust log-level entries if I get the right ones. Otherwise probably a good idea for LND to purge duplicate Tor Addresses by default, no need to store and display those.
Debug Information
No response
Environment
No response
Metadata
Metadata
Assignees
Type
Projects
Status