TL;DR — decisión rápida

• Carril privado por defecto para gasto diario → Monero. Imposibilidad de enlazar obligatoria, subdirecciones por defecto, ningún observador correlaciona importes. Coste: menos aceptación en comercios.
• Lightning cuando el comercio acepta LN. Privacidad en recepción buena (sin reuso de direcciones); en emisión moderada (la ruta es privada para observadores, pero la contraparte del canal ve el origen). Encaja para gasto retail con velocidad.
• Bitcoin on-chain solo cuando no queda otra. Grafo público; el análisis on-chain está bien financiado; cualquier vínculo KYC pasado puede dejar ciertas UTXOs marcadas para siempre. Úsalo solo si el receptor exige BTC on-chain.

Perfil de fuga — qué expone cada carril

• Monero: el importe está oculto. Direcciones de emisor y receptor ocultas. Único observable: «hubo una transacción entre partes desconocidas». Un explorador no te da nada.
• Lightning: la topología y capacidad de canales es parcialmente observable. Los dos extremos se conocen; la ruta sabe saltos pero no extremos. Un observador agresivo con varios nodos de enrutamiento puede sondear y correlacionar pagos grandes. Los pagos pequeños del día a día se mantienen razonablemente privados.
• Bitcoin on-chain: cada pago es público, las direcciones quedan enlazadas para siempre a quien las recibió primero y el análisis agrupa direcciones por heurísticas (input común, change-address, timing). Si una dirección de un cluster se doxxea, el cluster entero también.

Recuperabilidad tras un error

• Monero: un error (p. ej. enviar desde una wallet etiquetada) queda contenido — la wallet en sí no se autodelata. El error filtra solo el vínculo que tú mismo expusiste.
• Lightning: un error (usar una contraparte que loggea mucho, o un LSP con KYC) se recupera cerrando el canal y reabriendo con otro LSP. Los pagos previos a la rotación siguen siendo visibles para la contraparte vieja.
• Bitcoin on-chain: los errores son prácticamente permanentes. Volver a gastar de una UTXO «tainted» propaga el vínculo. La recuperación requiere romper el enlace con un swap (ver romper un enlace de análisis on-chain).

Cuándo es cada carril la opción correcta

• Pagos privados recurrentes a gente que acepta XMR: Monero. No le des más vueltas; para eso existe el protocolo.
• Café / retail online / propinas en comercios que aceptan LN: Lightning. Velocidad + comisiones bajas + rotación inherente en recepción encajan en la escala de compra diaria.
• Movimientos de tesorería crypto-nativos (grandes, infrecuentes): Monero con un nodo propio (run-a-monero-node) para soberanía. Si el destino exige BTC, ruta via XMR-detour (kyc.rip/ghost) — nunca BTC on-chain directo desde una fuente KYC.
• Recibir de una fuente pública (p. ej. facturación de clientes) a una wallet privada: Lightning si la fuente soporta LN. Si no, BTC on-chain + XMR-detour a wallet nueva.
• Activo especificado como BTC on-chain por el receptor: cuando no hay opción, acepta la fuga, pero aísla esa wallet de todo lo demás.

Coste operativo / fricción

• Monero: instalar Feather / Cake / GUI; nodo remoto o propio. Comprar XMR via P2P no-KYC (RoboSats, Bisq, Haveno) o swap no-KYC. Fricción diaria: baja. Onboarding: moderado (los nuevos subestiman lo «Just Works» que es).
• Lightning: instalar Phoenix / BlueWallet / Zeus / Mutiny. Abrir al menos un canal (LSP gestionado para la mayoría). Fricción diaria: baja en el gasto; fricción de setup: real (~1-2 h hasta entender). Rebalanceo de canal cada cierto tiempo.
• Bitcoin on-chain: el más fácil de empezar (más wallets, soporte más amplio). Fricción diaria: comisiones altas + confirmación lenta. Fricción de privacidad: invisible hasta que cometes un error.

Setups híbridos que la gente realmente usa

• Monero para el día a día, Lightning para comercios: el grueso en XMR, swap de pequeñas cantidades a LN cuando hace falta. Puentes vía swap no-KYC o boltz. XMR es almacenamiento privado; LN es gasto privado.
• BTC-cold + XMR-warm + LN-spend: tres wallets, tres roles. BTC frío = inversión (apenas se mueve), XMR templado = puente de privacidad (XMR-detour hacia donde haga falta), LN = gasto diario. Más fricción, postura de privacidad más fuerte.
• Wallet XMR única: minimalista. Solo práctico si tu gasto cae mayormente en comercios que aceptan XMR. Mínima carga cognitiva.

Errores frecuentes

• Comprar XMR en un exchange KYC y asumir «ya es privado»: el on-ramp ligó tu identidad al retiro. El XMR es privado a partir de ese punto, pero el registro «nombre real compró N XMR en T» queda. Mitiga con P2P o swap desde un saldo ya desligado.
• Tratar Lightning como totalmente privado end-to-end: el LSP / contraparte de canal ve más que un observador casual. Vale para gasto diario; no sustituye a XMR para flujos de alto riesgo.
• Reusar direcciones BTC on-chain: cada recepción en la misma dirección revela más de la wallet. Usa una wallet que genere dirección nueva por pago (Sparrow, BlueWallet) y trata el reuso como decisión deliberada (p. ej. tip jar pública).
• Optimizar por máxima privacidad cuando el modelo no la requiere: ver modelos de amenaza. Mucha gente está bien en Lightning; la sobrecorrección a «todo XMR» mete fricción que les empuja de vuelta al KYC.