AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 34 Bitcoin

multi: drop tor v2 onion production, keep wire codec faithful

Public commit record

What the developer wrote

Authored by Erick Cestari

88/100 · Strong
multi: drop tor v2 onion production, keep wire codec faithful

Tor stopped serving v2 onion services in October 2021; lnd should not
produce v2 addresses anymore, but it must still verify signatures on
and re-broadcast peer NodeAnnouncement messages that carry v2 entries.

Stop accepting v2 as configuration input (lncfg), strip the legacy
`--tor.v2` flag from the sample config, and remove the
`tor.OnionHostToFakeIP` helper. Operator entry points (`--externalip`,
`--listen`, `lncli connect`, `lncli wtclient towers add`) fail fast on
a v2 `.onion` string, so upgrading nodes must remove any v2 entry from
`lnd.conf` before lnd will start.

Filter persisted v2 state before use without rewriting on-disk records:
the self-announcement builder strips any v2 entry inherited from the
stored self-node; the watchtower client drops v2 entries from each
persisted tower's address list (skipping the tower entirely if no
non-v2 address remains); the autopilot connector, graph bootstrapper,
and static-channel backup restore paths skip v2 entries before
attempting outbound dials. Restrict the Tor controller's ADD_ONION
path to v3 keys, including the encrypted on-disk legacy-key fallback.

For inbound announcements, keep the wire codec wire-faithful:
`lnwire.WriteOnionAddr`, `graph/db.encodeOnionAddr`, and the matching
decoders round-trip v2 bytes so `DataToSign` reproduces the bytes the
remote peer signed, signature validation succeeds, and the announcement
is persisted to the graph DB and re-broadcast across restarts byte-for-
byte. RPC surfaces continue to expose the full address set so external
tools can independently reproduce and verify the signed bytes.

Add a netann regression test that signs a [v3, v2, ipv4] announcement,
round-trips it through Encode/Decode, verifies the signature, and
confirms the resulting models.Node preserves the v2 entry. Add a
graph bootstrapper test asserting v2 entries are skipped while v3 and
plain TCP entries on the same node still surface as bootstrap
candidates.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit removes support for obsolete Tor v2 onion addresses from the Lightning Network Daemon (lnd). Tor v2 services were shut down by the Tor network in October 2021, so lnd will no longer create, accept, or dial v2 onion addresses. However, it still keeps the ability to store and re-broadcast v2 addresses that appear in messages from other nodes, because doing otherwise would break signature verification on those older announcements. The change is a cleanup and hardening patch rather than a fix for an active security vulnerability.

Recommended action

Operators upgrading to this commit should remove any tor.v2 config lines and any v2 .onion addresses from lnd.conf, externalip, listen, addpeer, or watchtower tower addresses before starting lnd. If a v2 onion private key file exists, delete it so lnd can generate a fresh v3 service. No emergency response is needed; this is a planned deprecation hardening change.

Security signals we found

01

Removal of deprecated network protocol (Tor v2) reduces attack surface and prevents futile/unsafe dials to unreachable services.

02

Input validation added at operator boundaries (ParseAddressString, parseAddr) to reject v2 .onion addresses with a clear error.

03

On-disk legacy key fallback now validates decrypted key type and rejects non-v3 (RSA1024) keys before passing them to Tor.

04

Persistent state is filtered before use but not rewritten, preserving wire fidelity for peer-signed NodeAnnouncement validation and re-broadcast.

05

Watchtower client skips towers whose only persisted addresses are v2, preventing stuck/unreachable tower sessions.

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 7/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.