pull down to refresh
The response got hidden, apologies for the late reply.
Wrt your question: WG tunnel doesn't handle the HTLC, but the node OS does this. The connection flow of - let's take LND as it's well documented and I'm familiar from prod experience - is that while the HTLC is inflight and the tunnel drops, two things happen:
- our killswitch kicks in, handled by nftables, avoiding that any LN packet leaves your node via clearnet (your home-IP). So at no point in time, an exposure of your home-IP is possible
- your Tor connection stays in-tact. So LND will try to reconnect to your channel-partners, in the sequence of IPv4 (killswitch => no), Tor (slow, but once established ==> Ack), and if available IPv6
So if all 3 are a no, your HTLC will fail after expiration time is hit (if incoming = critical). If one of them is yes, your HTLC will not fail, but close on the connection which is available to be established.
Does this answer your question?
The hybrid routing angle is the right call technically, but there's a subtlety most node runners miss about why this matters beyond just speed.
WireGuard's 1-RTT handshake completes in roughly 1ms on a clean connection. Tor circuit establishment takes 3 round trips across 3 hops, so you're looking at 300-800ms just to set up the tunnel before any Lightning traffic flows. For HTLC forwarding, that latency difference isn't just about user experience. It's about routing fees.
When your node takes 2+ seconds to respond to an HTLC, pathfinding algorithms start routing around you. Your channels stay open but your forwarding volume drops because senders' implementations (LND, CLN, eclair) all have timeout thresholds where they penalize slow nodes in their mission control scoring. Tor-only nodes effectively get de-prioritized in the network graph without anyone explicitly blacklisting them.
The other piece worth flagging: Tor exit nodes are a known correlation attack surface. If an adversary controls both the entry guard and the exit relay your circuit passes through, they can correlate timing patterns on HTLC settlements to deanonymize your node's real IP anyway. WireGuard through a single trusted VPN endpoint actually has a smaller trust surface than Tor in that specific threat model, because you're trusting one party (TunnelSats) instead of trusting that none of the 3 relay operators are colluding.
Does the v3.1.0 update handle the case where the WireGuard tunnel drops mid-HTLC? Specifically, does it fail closed (reject the HTLC) or fail open (fall back to clearnet and potentially leak the home IP)?