Canales y enrutamiento Lightning: cómo encuentran su camino los pagos

Un canal Lightning es un saldo compartido entre dos nodos: una cantidad fija de bitcoins que pasa de un lado al otro con los pagos. En la lección 4.1 viste cómo funciona la red Lightning. Esta lección profundiza en los canales, la liquidez de entrada (por qué una billetera o nodo nuevo a menudo no puede recibir), cómo los pagos encuentran un camino por la red y las facturas BOLT11 que llevan todo lo que necesita quien paga.

Entiende los canales Lightning en profundidad

Cada canal Lightning tiene una capacidad fija, establecida por la transacción de financiación. Si Alice abre uno con Bob y aporta 0,05 BTC, su capacidad es de 0,05 BTC. Sigue así hasta que se cierre o cambie de tamaño con una técnica más nueva llamada splicing.

Capacidad del canal

La capacidad es un límite estricto. Ningún pago por un canal puede ser mayor que su capacidad: uno de 500 000 sats no puede llevar un pago de 600 000 sats, sea cual sea el reparto del saldo.

Un canal puede financiarse por un lado (financiación individual) o por ambos (financiación dual). Uno de financiación dual empieza con dinero a ambos lados, así que las dos partes pueden enviar y recibir desde el principio.

Saldo local y remoto

Dentro de un canal, la capacidad se divide en dos saldos:

• Saldo local: la cantidad de tu lado. Es lo que puedes enviar.
• Saldo remoto: la cantidad del lado de la otra parte. Es una estimación de lo que puedes recibir.

Ambos suman la capacidad, menos unas cantidades que el protocolo aparta:

• La reserva del canal: cada parte debe conservar una pequeña parte del canal que no puede gastar, así siempre tiene algo que perder si intenta hacer trampa publicando un saldo antiguo. La especificación de Lightning sugiere el 1 % del canal (BOLT 2). La reserva no puede ser inferior al límite de polvo, que BOLT 2 fija en 354 sats como mínimo. Por eso en un canal pequeño supera el 1 %: al menos 354 sats en un canal de 25 000 sats, donde el 1 % serían 250. Una parte que aún no alcanza su reserva, como la otra parte de un canal que acabas de financiar, puede recibir, pero no puede enviar hasta que tenga más que su reserva (BOLT 2).
• Dinero reservado para las comisiones de cierre, por si hay que forzar el cierre del canal. Este importe sube y baja con las comisiones on-chain y puede ser considerable. En la mayoría de los tipos de canal, quien abrió el canal paga la comisión incluida en la transacción de cierre forzado. Así que el dinero sale del saldo de esa parte (BOLT 2).
• Pagos en curso, que inmovilizan parte del saldo hasta terminar.

La documentación de Phoenix da un ejemplo: un canal con un saldo de 5000 sats y una capacidad de 25 000 sats no puede recibir realmente 20 000 sats, porque parte del espacio restante queda bloqueado por estos motivos (preguntas frecuentes de Phoenix). Por eso «lo que puedes recibir» siempre es un poco menos de lo que parece.

Los canales son bidireccionales

El dinero se mueve en ambas direcciones: si Alice paga 10 000 sats a Bob y él le paga después 5000, parte vuelve. Un canal usado en ambos sentidos conserva el equilibrio.

Liquidez de entrada y de salida

La liquidez de entrada es lo que más confunde a los principiantes y el motivo más común de que falle un pago dirigido a ellos.

Imagina el canal como un alambre con un número fijo de bolitas, como un ábaco. El número de bolitas es la capacidad. Cada pago las desliza por el alambre: pagar las mueve hacia la otra parte y recibir las mueve hacia ti. Solo puedes deslizarlas hacia ti si hay algunas en el extremo de la otra parte.

Liquidez de salida

La liquidez de salida son las bolitas de tu extremo: el saldo local de todos tus canales y lo máximo que puedes enviar. Cuando abres un canal y lo financias tú, toda la cantidad es de salida. Conseguirla es fácil: financia un canal y, en cuanto se confirme la transacción de financiación, podrás enviar.

Liquidez de entrada

La liquidez de entrada son las bolitas de los extremos de las otras partes: el saldo remoto de tus canales y lo máximo que puedes recibir, aproximadamente.

Esta es la trampa: abre un canal con 100 000 sats tuyos y las 100 000 bolitas estarán en tu extremo. Puedes enviar, pero nadie puede pagarte por ese canal porque no hay nada al otro lado que deslizar hacia ti.

Cómo conseguir liquidez de entrada

1. Gasta primero: cada pago que envías mueve bolitas al extremo de la otra parte, que podrás recibir después. Simplemente usar Lightning crea liquidez de entrada.
2. Pide que abran un canal contigo: cuando otro nodo lo abre y financia, todo el saldo queda de su lado, así que toda la cantidad es de entrada para ti. Los comercios suelen pedirlo.
3. Pasa a on-chain mediante un swap: un swap submarino es un intercambio entre Lightning y bitcoins on-chain, bloqueados juntos para que ninguna parte pueda hacer trampa. Enviar sats Lightning a un servicio de swaps y recibir bitcoins on-chain (un “Loop Out”, por la herramienta de Lightning Labs para nodos LND. Boltz, que ofrecía swaps parecidos desde cualquier billetera, está fuera de servicio desde el 3 de agosto de 2026) mueve bolitas al otro extremo de tu canal. La lección 4.4 explica los swaps.
4. Cómprala a un proveedor de servicios Lightning (LSP): una empresa que abre canales contigo por una comisión. Billeteras como Phoenix lo hacen automáticamente en segundo plano.
5. Canales de financiación dual: ambas partes aportan dinero al abrirlos, así que cada una empieza con liquidez de entrada y salida.

Phoenix, por ejemplo, gestiona la liquidez de entrada. Cuando llega un pago que no cabe, amplía tu canal y cobra el 1 % más la comisión de minería. Crear tu primer canal cuesta 1000 sats (tabla de comisiones de Phoenix). Si ejecutas tu propio nodo, gestionar esa liquidez es tarea tuya.

Cómo funciona el enrutamiento Lightning

Cuando pagas a alguien con quien no compartes canal, tu billetera debe encontrar un camino de canales conectados hasta esa persona. Es el enrutamiento.

Pagos de varios saltos

La mayoría de los pagos pasa por uno o varios nodos intermedios. Tu billetera evalúa las rutas por:

• Capacidad: ¿todos los canales de la ruta son lo bastante grandes?
• Saldo: ¿está el dinero en el lado correcto de cada canal? Los nodos publican la capacidad, pero no el reparto, así que la billetera tiene que estimarlo.
• Comisiones: ¿cuánto cobran todos los saltos juntos?
• Fiabilidad: ¿ha funcionado antes esta ruta?
• Número de saltos: menos saltos suelen ser más baratos y fiables.

El software de nodo, como LND y Core Lightning (CLN), recuerda qué pagos funcionaron y cuáles fallaron, y lo usa para elegir mejores rutas la próxima vez.

Enrutamiento cebolla

Lightning usa enrutamiento cebolla para la privacidad. Tu billetera envuelve las instrucciones de ruta en capas de cifrado, como una cebolla. Cada nodo quita una capa y conoce de dónde llegó el pago (el salto anterior), adónde enviarlo después y cuánto pasar. No hay nada más sobre la ruta escrito en su capa.

Un nodo en medio de la ruta normalmente no puede saber:

• quién inició el pago
• quién lo recibe al final
• cuánto mide la ruta

La excepción es el nodo justo a tu lado. Una billetera de teléfono suele tener un solo canal, con su LSP, y no reenvía pagos de otros. Así que, cuando sale un pago de ese canal, el LSP sabe que vino de ti. Del mismo modo, si quien cobra recibe por un canal privado (no anunciado al resto de la red, como la mayoría de los canales de billeteras de teléfono), el nodo anterior sabe quién cobra. Phoenix va más allá: entrega cada pago al nodo de ACINQ para buscar la ruta, así que ACINQ también ve adónde va (la lección 4.3 explica este inconveniente).

Cada nodo de la ruta sí ve más o menos cuánto se paga. A cada salto se le indica la cantidad que debe pasar, el pago más las comisiones pendientes de los saltos siguientes (BOLT 4), que es cercana al total. Dividir el pago en partes por rutas distintas (pagos por múltiples rutas) oculta el total a un salto que solo lleva algunas partes.

En cambio, on-chain, cualquiera que lea la blockchain ve la dirección de envío, la dirección de recepción y la cantidad.

Las comisiones de enrutamiento como incentivo

Los nodos intermedios cobran una comisión por reenviar. Les compensa por mantener bitcoins bloqueados en canales y seguir conectados, y orienta las billeteras a rutas más baratas. Cada nodo fija una comisión base por pago y una tasa en partes por millón (ppm) de la cantidad. La comisión de un salto es:

fee = base fee + amount × rate ÷ 1,000,000

La lección 4.1 calcula una ruta de dos saltos con las comisiones medianas de la red: unos 3 sats para 10 000 sats y unos 21 sats para 100 000. La lección 4.8 explica cómo fijar tus comisiones como nodo de enrutamiento, y nuestra guía de comisiones de la red Lightning profundiza en ello.

Cómo funcionan las facturas Lightning

Para cobrar por Lightning, quien recibe crea una factura Lightning: una solicitud de pago con todo lo que necesita la billetera de quien paga para construirlo.

Facturas BOLT11

BOLT11 es el formato de factura más usado. Una factura es una cadena larga, que empieza por lnbc en la red principal de Bitcoin, y contiene:

• Hash del pago: la huella del secreto que revelará quien recibe al cobrar. Esto hace funcionar los HTLC (lo explica la lección 4.1).
• Cantidad: opcional. Una factura de «cantidad cero» deja elegir a quien paga.
• Vencimiento: cuánto tiempo sigue válida. El valor por defecto de la especificación, usado si la factura no lo indica, es una hora (BOLT 11), pero las billeteras fijan el suyo: LND, por ejemplo, crea facturas válidas durante 24 horas salvo indicación contraria.
• Descripción: una nota como “Coffee at Bitcoin Café”.
• Indicaciones de ruta: últimos saltos sugeridos, necesarios cuando los canales del destinatario son privados.
• Identidad del nodo del destinatario: su clave pública, que indica adónde enviar. También dice a cualquiera que vea la factura a qué nodo se paga.

Las facturas suelen mostrarse como códigos QR. Escanea una con tu billetera Lightning, que lee todo eso y construye el pago.

Una factura BOLT11 solo se puede pagar una vez. Si otra persona intenta pagar la misma, el pago falla.

Ofertas BOLT12

BOLT12 es un formato más nuevo que resuelve varias limitaciones de BOLT11:

• Reutilizable: una oferta se puede pagar muchas veces, útil para una página de donaciones o un bote de propinas. En segundo plano, la billetera de cada persona pide una factura nueva al destinatario.
• Cantidad elegida después: quien paga puede fijarla en el momento del pago.
• Mejor privacidad: una oferta puede ocultar el nodo del destinatario detrás de «rutas cegadas» en vez de nombrarlo. En una ruta cegada, el destinatario elige los últimos saltos y los cifra, así que quien paga solo conoce el nodo donde empieza ese tramo oculto.
• Reembolsos: el formato permite que un comercio pague a un usuario, por ejemplo para reembolsarlo.
• Pruebas de quien paga: puede demostrar que fue quien pidió la factura, no solo que alguien la pagó.

El soporte de BOLT12 sigue extendiéndose por las billeteras y el software de nodo. Core Lightning (CLN) lideró su desarrollo. Nuestra guía sobre BOLT11 y BOLT12 los compara con más detalle.

Buenas prácticas para gestionar canales Lightning

Si usas una billetera como Phoenix, gestiona los canales por ti. Si ejecutas tu nodo, es tarea tuya y se resume en tres hábitos: mantener útiles los canales en ambos sentidos (reequilibrarlos), cerrar los inactivos y abrir canales con pares fiables y bien conectados. La lección 4.8 explica cada uno para quienes operan nodos, incluido el costo de reequilibrar, y nuestra guía avanzada de gestión de canales profundiza en ello.

Problemas comunes de enrutamiento

Incluso los canales bien gestionados fallan a veces al entregar un pago. Conocer las causas habituales te ayuda a resolverlos rápido.

No se encuentra una ruta

Tu billetera no encontró ningún camino al destinatario. Entre las causas están:

• el nodo del destinatario está desconectado o no tiene canales públicos
• no hay un camino conectado entre tu nodo y el suyo
• ninguna ruta posible tiene capacidad suficiente

Solución: abre canales con nodos bien conectados o pide una factura nueva con indicaciones de ruta al destinatario.

Liquidez insuficiente

Hay una ruta, pero uno o varios de sus canales no tienen suficiente dinero del lado correcto. Pasa a menudo con los pagos grandes.

Solución: prueba una cantidad menor, usa pagos por múltiples rutas (MPP) para dividirla entre rutas o vuelve a intentarlo después, cuando se hayan movido los saldos.

Se supera la capacidad del canal

El pago es mayor de lo que un canal de la ruta puede llevar, sea cual sea su saldo.

Solución: divide el pago con MPP o busca rutas por canales mayores.

Se agotó el tiempo del pago

Tu billetera probó rutas durante un tiempo y dejó de iniciar intentos nuevos. Suele indicar nodos lentos o que no responden en las rutas probadas. Pero un intento que ya salió puede seguir en camino: software como LND no cancela un pago mientras parte de él siga en curso (documentación del enrutador de LND).

Solución: espera a que el pago deje de aparecer como pendiente y vuelve a intentarlo. La billetera normalmente evitará el nodo problemático la próxima vez. Si sigue pendiente, es el siguiente caso.

Un pago atascado hasta que venza su HTLC

Es un problema distinto y más raro. A veces sale un pago de tu billetera, pero un nodo posterior deja de responder y el pago queda “pending”. El HTLC de cada salto tiene un plazo en bloques y tus fondos quedan bloqueados hasta que el pago termine o llegue al plazo. Puede tardar horas o días: LND acepta reenvíos bloqueados hasta 2016 bloques, unas dos semanas (configuración de ejemplo de LND). Si llega el plazo y el HTLC aún no puede resolverse correctamente, el protocolo exige cerrar on-chain el canal que lo contiene (BOLT 2): un cierre forzoso con comisiones on-chain.

Solución: volver a intentarlo no hace nada aquí. Mantén la billetera o el nodo conectado y espera. Phoenix, por ejemplo, pide dejar encendido el teléfono y abrir la aplicación de vez en cuando hasta que el pago se resuelva como fallido (preguntas frecuentes de Phoenix).

Nuestra guía para resolver pagos Lightning fallidos tiene más casos y soluciones paso a paso.

Preguntas frecuentes

¿Qué diferencia hay entre liquidez de entrada y de salida?

La liquidez de salida son los bitcoins de tu lado de los canales, lo máximo que puedes enviar. La liquidez de entrada son los del otro lado, una cantidad cercana al máximo que puedes recibir. Un canal que abres y financias tú empieza con toda la liquidez de salida y ninguna de entrada. Al gastar, la de salida se vuelve de entrada. Por eso los nodos nuevos a menudo no pueden recibir hasta gastar o comprar capacidad de entrada.

¿Puedo ampliar la capacidad de un canal sin cerrarlo?

Sí, con splicing, que añade o quita fondos de un canal existente con una transacción on-chain. El canal sigue funcionando mientras se confirma el cambio. Phoenix usa splicing para cambiar automáticamente el tamaño de su canal. Todavía no lo admiten todas las implementaciones de Lightning.

¿Cómo decodifico una factura Lightning para ver qué lleva?

La mayoría de las billeteras muestra los detalles al escanear una factura. En tu nodo, lncli decodepayreq <invoice> (LND) o lightning-cli decode <invoice> (CLN) muestra cada campo. También hay decodificadores en línea, pero evita pegar facturas con datos de pago reales en webs de terceros: revelan el nodo que cobra y la cantidad.

¿Por qué fallan algunos de mis pagos Lightning?

Lo habitual es falta de liquidez en la ruta, destinatario desconectado, factura vencida o pago mayor que los canales del camino. Las billeteras prueban otras rutas automáticamente. Si los fallos siguen, suele ayudar abrir canales con nodos mejor conectados o usar una billetera con LSP integrado.

¿Qué pasa con mis fondos si se desconecta un nodo intermedio de enrutamiento?

No los pierdes, pero quizá debas esperar desde unas horas a unos días, y hasta unas dos semanas en el peor caso, hasta que el pago termine o pase el plazo del HTLC. La mayoría de los pagos atascados se resuelve después como fallido y el dinero vuelve por Lightning. Si no puede resolverse como fallido, se fuerza el cierre de un canal de la ruta. Suele ser el vecino del nodo que no responde. El tuyo solo se cierra si ese nodo es la otra parte directa o tu billetera está desconectada al llegar el plazo, y entonces los fondos vuelven on-chain, menos las comisiones. Mantén conectada la billetera mientras tanto. La sección «Un pago atascado hasta que venza su HTLC» de arriba explica por qué.

Comprueba lo que entendiste

1. Abres un canal de 200 000 sats y lo financias tú. Un amigo intenta pagarte 10 000 sats por él. ¿Qué pasa y qué podrías hacer primero?

Respuesta

El pago falla: los 200 000 sats están de tu lado, así que no hay liquidez de entrada. Podrías gastar algunos sats por él, pasar algunos a on-chain con un swap, pedir a otro nodo que abra un canal contigo o comprar liquidez de entrada a un LSP.

2. Un nodo de enrutamiento reenvía tu pago. ¿Qué puede ver: quién eres, quién recibe el pago o cuánto se paga más o menos?

Respuesta

Siempre ve la cantidad que reenvía, cercana al total si se envía de una pieza: a cada salto se le indica la cantidad que debe pasar, el pago más las comisiones pendientes de los saltos siguientes. Que sepa quién eres o quién cobra depende de su posición. Un nodo intermedio normalmente no puede porque el enrutamiento cebolla oculta ambos. Pero si es el LSP de tu billetera y tu único canal, sabe que el pago vino de ti y, con Phoenix, ACINQ también ve el destino. Del mismo modo, el nodo anterior a un destinatario con un solo canal privado sabe quién cobra.

3. Tu billetera dice “payment timed out”. Hace una semana otro pago quedó “pending” durante días. ¿Por qué deberías tratarlos de forma distinta?

Respuesta

Que se agote el tiempo significa que tu billetera dejó de probar rutas nuevas. Cuando deje de aparecer como pendiente, no hay nada bloqueado y puedes reintentarlo. Un pago que sigue pendiente está bloqueado en HTLC a lo largo de una ruta. Reintentarlo no ayuda: mantén conectada la billetera y espera a que termine o pase el plazo. Si no puede resolverse como fallido, se fuerza el cierre de un canal de la ruta, posiblemente el tuyo, y tus fondos de ese canal vuelven on-chain.