Cómo usar Bitcoin Lightning de forma anónima

El default es peor de lo que se cree

• Wallets custodial (Wallet of Satoshi, Strike, Cash App) — tus sats están en sus libros. Ven cada pago, pueden congelar la cuenta, y casi todos KYC-ean al alta o antes del primer retiro. Cómodo, no privado.
• Mobile self-custody (Phoenix, Breez, Mutiny, Zeus) — vos tenés las llaves; el LSP rutea por vos. Algún metadata se filtra al LSP, pero podés rotar LSPs o correr el tuyo.
• Nodo self-hosted (LND / Core Lightning) — soberanía total. Techo de privacidad más alto, costo operativo continuo real.

Wallets móviles que realmente preservan privacidad

• Phoenix: el estándar oro para LN mobile self-custody. Splicing significa que no abrís/cerrás canales manualmente. ACINQ actúa como LSP — ven tu canal partner, no todo tu grafo de pagos. Open source.
• Mutiny: browser-first, self-custody, integrado con Nostr. LSP pluggable. Open source.
• Zeus: front-end mobile para un nodo remoto LND/CLN que controlás vos. Mejor privacidad + flexibilidad, requiere correr el backend.
• Breez: self-custody con Lightning nativo + Liquid + swaps boltz integrados. Open source.

La elección del LSP importa

Tu Lightning Service Provider ve cada apertura de canal con vos. Algunos LSPs además huelen patrones de pago. Defensas:

• Rotá LSPs. No abras todos los canales contra el mismo operador.
• Splice en vez de abrir canales nuevos. Reusa UTXOs existentes y evita nuevos fingerprints on-chain. Phoenix lo hace por default.
• Migrar Wallet of Satoshi → self-custody: mové los sats con un swap-out, no con un withdraw directo — los withdraws directos dejan un audit-trail LN clarísimo.

Onboarding sin KYC

Cómo meter sats en una wallet Lightning self-custody sin pasar por un exchange con KYC:

1. Swap XMR → LN. Usá un engine sin KYC (SideShift, kyc.rip) para mandar XMR y recibir Lightning a tu invoice. Es el path más limpio, sin fingerprint on-chain. Si tu input es USDT/USDC o BTC on-chain y querés un flujo único con XMR-detour hacia LN, kyc.rip / ghost hace los dos hops en una sola submission.
2. P2P en un meetup. Intercambiá efectivo por sats con una persona real; que pague tu invoice LN. RoboSats lo soporta para contrapartes arbitrarias.
3. RoboSats / Bisq Lightning. P2P fiat→LN. Algo de fricción de cuenta; las contrapartes son pseudónimas.
4. Sats ganados. Cobrá en LN por trabajo / contenido. Evita el problema de onboarding por completo.

Recibir sats sin exponerte

• Las invoices LN son de un solo uso. Generá una invoice fresca por pago; nunca las reutilices.
• Lightning Address (user@domain) es un identificador fijo. Cómodo para propinas pero revela tu vínculo con el operador del dominio. Usá un host respetuoso con la privacidad (ej. zeusln.app, el tuyo propio).
• LNURL-Pay se comporta como Lightning Address — mismo caveat. Corré tu propio endpoint LNURL para privacidad completa.
• Bolt12 offers — protocolo más nuevo, soporta respuestas onion-routed. Mejor privacidad que LNURL una vez que tu wallet lo soporte.

Enviar sats — qué leakea

1. Emisor: tus nodos de routing ven (prefijo de la ruta, monto, payment hash). Sphinx routing oculta el destino a los hops intermedios.
2. Receptor: los nodos de routing del receptor ven lo mismo al revés. Aprenden el monto y el hash pero no el emisor.
3. Probing attacks: analistas con fondos prueban canales para desanonimizar rutas. Canales más grandes + más hops = mejor privacidad.
4. JIT (just-in-time) channel opens te exponen al LSP en el momento de la apertura. Splice por sobre open siempre que se pueda.

Cuándo Lightning no es lo correcto

Lightning es excelente para pagos chicos y frecuentes. Es un vehículo de ahorro pobre (riesgo de canal, llaves online). Tratalo como una caja de ahorros corriente; usá Monero nativo o BTC on-chain como savings. El puente entre ambos lo hacen los engines XMR↔LN listados abajo.