How to use Bitcoin Lightning anonymously

The default is worse than people think

• Custodial wallets (Wallet of Satoshi, Strike, Cash App) — your sats sit on their books. They see every payment, can freeze the account, and most KYC at signup or before first withdrawal. Convenient, not private.
• Non-custodial mobile (Phoenix, Breez, Mutiny, Zeus) — you hold the keys; the LSP routes for you. Some metadata leaks to the LSP, but you can swap LSPs or run your own.
• Self-hosted node (LND / Core Lightning) — full sovereignty. Highest privacy ceiling, real ongoing operational cost.

Mobile wallets that actually preserve privacy

• Phoenix: the gold standard for non-custodial mobile LN. Splicing means you don't open/close channels manually. ACINQ acts as LSP — they see your channel partner, not your full payment graph. Open-source.
• Mutiny: browser-first, non-custodial, Nostr-integrated. Pluggable LSP. Open-source.
• Zeus: mobile front-end for a remote LND/CLN node you control. Best privacy + flexibility, requires running the backend.
• Breez: non-custodial with native lightning + Liquid + boltz swaps built in. Open-source.

LSP choice matters

Your Lightning Service Provider sees every channel-open with you. Some LSPs additionally sniff payment patterns. Defenses:

• Rotate LSPs. Don't open every channel against the same operator.
• Splice rather than open new channels. Reuses existing UTXOs and avoids new onchain fingerprints. Phoenix does this by default.
• Wallet-of-Satoshi → non-custodial migration: move sats to a non-custodial wallet via a swap-out, not a direct withdrawal — direct withdrawals leave a clear LN audit trail.

Onboarding without KYC

Getting sats into a non-custodial Lightning wallet without going through a KYC'd exchange:

1. XMR → LN swap. Use a no-KYC swap engine (SideShift, kyc.rip) to send XMR and receive Lightning to your invoice. Cleanest non-onchain-fingerprint path. If your input is USDT/USDC or onchain BTC and you want a single-flow XMR-detour into LN, kyc.rip / ghost handles both legs in one submission.
2. P2P at a meetup. Trade cash for sats with a real person; have them pay your LN invoice. RoboSats supports this for arbitrary counterparties.
3. RoboSats / Bisq Lightning. P2P fiat→LN. Some account-friction; counterparties are pseudonymous.
4. Earned sats. Get paid in LN for work / content. Avoids the onboarding problem entirely.

Receiving sats without exposing yourself

• LN invoices are one-shot. Generate a fresh invoice per payment; never reuse.
• Lightning Address (user@domain) is a fixed identifier. Convenient for tips, but reveals a relationship to the domain operator. Use a privacy-respecting host (e.g. zeusln.app, your own).
• LNURL-Pay behaves like a Lightning Address — same caveat. Run your own LNURL endpoint for full privacy.
• Bolt12 offers — newer protocol, supports onion-routed responses. Better privacy than LNURL once your wallet supports it.

Sending sats — what leaks

1. Sender: your routing nodes see (route prefix, amount, payment hash). Sphinx routing hides the destination from intermediate hops.
2. Receiver: their routing nodes see the same backwards. They learn the amount and hash but not the sender.
3. Probing attacks: well-funded analysts probe channels to deanonymize routes. Larger channels + more hops = better privacy.
4. JIT (just-in-time) channel opens reveal you to the LSP at open time. Splice over open whenever possible.

When Lightning is wrong

Lightning is excellent for small, frequent payments. It's a poor savings vehicle (channel risk, online keys). Treat it as a checking account, native Monero or onchain BTC as savings. Bridge between them via the XMR↔LN swap engines listed below.