Cómo resolver fallos de pago en Lightning

Un pago de Lightning puede fallar antes de salir de tu nodo o en un nodo de la ruta. También puede quedarse atascado por el camino. Un canal puede terminar en un cierre forzado que bloquee tus fondos durante un tiempo. Esta guía explica qué significa cada error habitual, cómo diagnosticarlo con comandos y cómo resolverlo. Abarca desde los problemas de liquidez hasta la conectividad del nodo y la recuperación.

Los comandos son para LND (lncli). Core Lightning (CLN) y Eclair usan otros mensajes de error, pero las causas son las mismas y la lógica de las soluciones también.

Fallos de pago habituales y códigos de error

Cuando falla un pago en Lightning, aparecen códigos de error concretos. En LND, cada pago fallido termina con un motivo, como NO_ROUTE, INSUFFICIENT_BALANCE o TIMEOUT. Durante la búsqueda, los nodos de la ruta pueden devolver errores de reenvío en intentos individuales. Tu nodo usa esos datos para volver a intentarlo. Estos son los errores más frecuentes y lo que significan.

FAILURE_REASON_NO_ROUTE

Tu nodo no encuentra una ruta por la red capaz de llevar el pago al destino. Puede que no haya ninguna desde el principio y el pago ni siquiera salga de tu nodo. O que el nodo pruebe todas las que encuentra y fallen todas.

Causas habituales:

• Ningún canal tiene liquidez de salida suficiente para ese importe
• El nodo de destino está sin conexión o no tiene canales públicos
• En todas las rutas posibles hay nodos intermedios sin conexión
• El grafo de canales de tu nodo está desactualizado o incompleto
• El importe supera el tamaño máximo de HTLC en las rutas disponibles

Diagnóstico:

Comprueba primero la liquidez de salida de todos tus canales:

lncli listchannels | jq '[.channels[] | select(.active==true)] | map({alias: .peer_alias, local: .local_balance, remote: .remote_balance, capacity: .capacity}) | sort_by(-.local | tonumber)'

El resultado muestra tus canales activos ordenados por el saldo de salida (local) disponible. Si ningún canal tiene liquidez de salida suficiente por sí solo, el pago no puede salir de una vez. Los pagos en varias partes (MPP) pueden repartir el importe entre varios canales.

Comprueba si hay alguna forma de llegar al destino:

lncli getnodeinfo --pub_key=DESTINATION_PUBKEY

Si aparece un error, el nodo de destino no figura en tu grafo o no tiene canales públicos. Comprueba que el grafo esté actualizado:

lncli getnetworkinfo

Compara num_nodes y num_channels con las estadísticas conocidas de la red. Si tus cifras son considerablemente más bajas, el grafo necesita actualizarse. Por lo general basta con reiniciar el nodo o esperar a que se propaguen los anuncios de la red.

Soluciones:

• Abre un canal directo al destino o a un nodo bien conectado que esté cerca del destino
• Usa Lightning Loop para reequilibrar los canales existentes y aumentar la liquidez de salida
• Deja que el pago se divida. lncli payinvoice ya lo hace, por defecto en un máximo de 16 partes (--max_parts). En otras billeteras, comprueba que los pagos en varias partes estén activados
• Si no dispones de MPP, reduce el importe y haz varios pagos más pequeños
• Espera y vuelve a intentarlo. Los cortes temporales de los nodos de enrutamiento se resuelven solos

FAILURE_REASON_INSUFFICIENT_BALANCE

El saldo que puedes gastar entre todos tus canales no cubre el importe. LND lo comprueba antes de buscar una ruta, así que el pago nunca sale de tu nodo. Si el total es suficiente pero ningún canal cubre el importe por sí solo, LND intenta dividirlo. Si tampoco funciona ninguna división, el pago falla con NO_ROUTE.

Causas habituales:

• La reserva obligatoria del canal ocupa parte de tu saldo, por lo general el 1 % de la capacidad del canal
• Los HTLC en curso (pagos que siguen en camino) bloquean liquidez hasta que se liquidan o fallan
• Las comisiones de enrutamiento se suman al importe. Si tu saldo cubre el importe pero no las comisiones, el pago falla con NO_ROUTE
• Las actualizaciones pendientes del canal todavía no se reflejan en tu saldo

Diagnóstico:

Busca HTLC pendientes que puedan estar bloqueando fondos:

lncli listchannels | jq '.channels[] | select(.pending_htlcs | length > 0) | {chan_id: .chan_id, alias: .peer_alias, pending_htlcs: .pending_htlcs}'

Compara el saldo que puedes gastar con el saldo que se muestra:

lncli walletbalance
lncli channelbalance

En channelbalance, local_balance es el importe que hay ahora de tu lado. Un pago que aún estás enviando ya ha salido de ese saldo y figura en unsettled_remote_balance hasta que se liquide o falle. Los pagos entrantes que siguen en camino aparecen en unsettled_local_balance. La reserva del canal reduce aún más el saldo que puedes gastar. En un canal de 1 millón de sats, cuenta con unos 10 000 sats de reserva que nunca puedes gastar a través de ese canal.

Soluciones:

• Espera a que los HTLC pendientes se liquiden o fallen. Si uno falla, los fondos regresan a tu lado
• Incluye la reserva y las comisiones al calcular el saldo disponible. Siempre puedes gastar menos de lo que indica el saldo del canal
• Abre canales más grandes para que la reserva obligatoria pese menos
• Gestiona tus canales para mantener la liquidez equilibrada

FAILURE_REASON_TIMEOUT

Tu nodo siguió probando rutas hasta agotar el tiempo de espera del pago (60 segundos por defecto en LND) y dejó de iniciar intentos. Los intentos en camino siguen su curso. LND espera a que cada uno se liquide o falle, así que el pago puede aparecer como IN_FLIGHT durante un tiempo. Cuando indica FAILED, ya no hay fondos bloqueados y puedes reintentarlo. Si un intento tardío sale adelante, indica SUCCEEDED. En ese caso ya has pagado y no debes volver a hacerlo. Si el pago sigue en curso mucho tiempo, hay un intento atascado en un nodo de la ruta y puedes seguir los pasos de abajo.

Causas habituales:

• Un nodo intermedio se quedó sin conexión mientras reenviaba el pago
• El nodo de destino recibió el HTLC pero aún no ha completado el cobro
• La congestión de la red retrasa el reenvío a lo largo de la ruta
• Un nodo de la ruta usa una implementación lenta o sobrecargada

Diagnóstico:

Busca pagos en curso:

lncli listpayments --include_incomplete | jq '.payments[] | select(.status=="IN_FLIGHT") | {hash: .payment_hash, amount: .value_sat, creation_date: .creation_date}'

Consulta el estado de los HTLC de ese pago:

lncli trackpayment PAYMENT_HASH

El resultado muestra en tiempo real el avance del pago por la red. Si el HTLC se queda atascado en un salto concreto, puedes ver qué nodo lo retiene.

Soluciones:

• Si hay un intento atascado, espera. Recuperas los fondos cuando falla o vence el plazo de su HTLC. LND acepta reenvíos con bloqueos de hasta 2016 bloques (unas dos semanas). Si un HTLC sigue sin poder liquidarse normalmente al vencer el plazo, el canal que lo retiene tiene que cerrarse on-chain
• NO envíes otro pago mientras uno siga en curso, porque podrías pagar dos veces
• Si te ocurre con frecuencia con el mismo nodo, plantéate cerrar ese canal
• Si sigues agotando el tiempo de espera sin que queden pagos atascados, aumenta el plazo con lncli payinvoice --timeout (60 segundos por defecto)
• Si el pago atascado termina en FAILED, vuelve a intentarlo. LND recuerda el fallo y suele elegir una ruta que evite ese nodo. Si termina en SUCCEEDED, el pago ya se completó, así que no pagues otra vez

Errores de reenvío de los nodos de la ruta

Cuando un nodo de la ruta no puede reenviar un intento, devuelve un error. LND lo registra en ese intento, dentro de la lista htlcs del pago, y sigue buscando. FAILURE_REASON_ERROR es un motivo de fallo definitivo que se reserva para errores menos frecuentes de los que LND no puede recuperarse. Estos son los errores de reenvío más habituales:

• FEE_INSUFFICIENT: tu nodo calculó una ruta con datos de comisiones desactualizados. El nodo de enrutamiento subió sus comisiones desde la última actualización del grafo.
• CHANNEL_DISABLED: uno de los dos nodos de un canal de la ruta lo ha desactivado, a menudo de forma temporal durante tareas de mantenimiento.
• TEMPORARY_CHANNEL_FAILURE: el nodo que debe reenviar el HTLC no puede procesarlo en ese momento. Suele ser un problema temporal de liquidez o capacidad en ese nodo.
• INCORRECT_CLTV_EXPIRY: el delta CLTV (CheckLockTimeVerify) no coincide con el que exige el nodo de enrutamiento. El grafo de tu nodo tiene datos desactualizados sobre la política de ese nodo.

La mayoría de estos errores se resuelven al reintentar. Tu nodo actualiza el grafo con los datos del error y elige otra ruta. Si un error concreto persiste, ejecuta lncli queryroutes --dest=PUBKEY --amt=AMOUNT para ver qué rutas intenta usar.

Problemas con los canales: cierres forzados y canales atascados

Los problemas con los canales son los que más preocupan a los operadores de nodos porque implican transacciones on-chain, periodos de espera y fondos bloqueados. Si operas un nodo de Lightning, necesitas entender los cierres forzados.

Canales con cierre forzado

Un cierre forzado ocurre cuando uno de los dos nodos del canal publica por su cuenta en la blockchain el estado más reciente del canal. Así evita el proceso de cierre cooperativo y activa un bloqueo temporal sobre tus fondos.

Por qué se fuerza el cierre de un canal:

• El otro nodo del canal estuvo sin conexión mucho tiempo y tu nodo dejó de esperar
• Tu nodo estuvo sin conexión y el otro nodo forzó el cierre para recuperar sus fondos
• Un HTLC pendiente está a punto de vencer on-chain y obliga a cerrar el canal para reclamarlo
• El estado del canal dejó de coincidir entre ambos nodos, algo infrecuente pero grave
• Tú o el otro nodo del canal forzaron el cierre por problemas de enrutamiento que no tenían solución

Cómo comprobar los cierres forzados pendientes:

lncli pendingchannels | jq '.pending_force_closing_channels[] | {channel_point: .channel.channel_point, limbo_balance: .limbo_balance, blocks_til_maturity: .blocks_til_maturity, recovered_balance: .recovered_balance}'

El campo blocks_til_maturity indica cuántos bloques faltan para que puedas gastar tus fondos. Si tú iniciaste el cierre forzado, esperas el plazo que fijó el otro nodo del canal al abrirlo. Con la configuración predeterminada de LND, son 144 bloques (alrededor de un día) en canales de menos de unos 1,2 millones de sats. El plazo aumenta con el tamaño del canal hasta 2016 bloques (unas dos semanas) en los más grandes. lncli listchannels muestra tu plazo como csv_delay en local_constraints. Si el otro nodo forzó el cierre, puedes gastar tu saldo un bloque después de que se confirme el cierre en los canales actuales con salidas ancla (anchor). Los HTLC pendientes complican el proceso.

Canales a la espera del cierre:

lncli pendingchannels | jq '.waiting_close_channels'

En estos canales, ya se ha difundido una transacción de cierre y aún no se ha confirmado. Con comisiones altas, este estado puede durar horas o días. Si la transacción corresponde a un estado anterior que el otro nodo ya no debería publicar, tu nodo responde con una transacción de penalización que se lleva todos los fondos del canal. Si tu nodo está sin conexión, puede responder tu watchtower.

Canales zombis

En un canal zombi, el nodo del otro extremo lleva mucho tiempo sin responder. El canal aparece como inactivo en tu lista, no puede enrutar pagos y mantiene bloqueados tus fondos.

lncli listchannels | jq '[.channels[] | select(.active==false and .private==false)] | length'

Si tienes muchos canales públicos inactivos, plantéate cerrarlos para liberar fondos on-chain y destinarlos a canales productivos. Antes de cerrar un canal, intenta volver a conectarte:

lncli connect PEER_PUBKEY@ADDRESS:PORT

Si el otro nodo del canal vuelve a estar conectado, el cierre cooperativo con lncli closechannel --chan_point=FUNDING_TXID:OUTPUT_INDEX es la forma más limpia de resolverlo. Si tras varios intentos sigue sin responder, el cierre cooperativo no es posible. Los dos nodos del canal tienen que firmarlo y LND rechaza el cierre cooperativo mientras el otro nodo está sin conexión. Añade --force para cerrar el canal por tu cuenta y ten en cuenta que tu saldo seguirá bloqueado durante el plazo indicado arriba.

Problemas de liquidez

Gestionar la liquidez es la tarea central de quien opera un nodo de Lightning. La mayoría de los fallos de pago se deben a desequilibrios de liquidez. La guía para optimizar el enrutamiento en Lightning cubre el tema en profundidad.

Liquidez de salida agotada

Después de enviar muchos pagos, tus canales se llenan del lado de los otros nodos. Tienes capacidad para recibir, pero no puedes enviar. En los pagos salientes, esto aparece como NO_ROUTE o INSUFFICIENT_BALANCE.

Diagnóstico:

lncli listchannels | jq '.channels[] | select(.active==true) | {alias: .peer_alias, local_pct: ((.local_balance|tonumber) / ((.local_balance|tonumber) + (.remote_balance|tonumber)) * 100 | floor)} | select(.local_pct < 20)'

El resultado muestra los canales activos en los que tu saldo local (de salida) está por debajo del 20 % de la capacidad. Esos canales necesitan un reequilibrio.

Opciones para reequilibrar:

• Reequilibrio circular: envíate un pago por la red. Hazlo salir por un canal que esté lleno de tu lado y volver por el canal agotado. Herramientas como bos rebalance (Balance of Satoshis) automatizan este proceso.
• Loop In: usa Lightning Loop para cambiar bitcoin on-chain por sats en Lightning que lleguen a tu lado de un canal. Así aumentas la capacidad de salida.
• Recibe por Lightning: es el reequilibrio más sencillo. Cada pago que recibes devuelve sats a tu lado.

Liquidez de entrada agotada

Es el problema contrario. Has recibido muchos pagos, los canales están llenos de tu lado y no puedes recibir más. Es frecuente entre comerciantes y proveedores de servicios.

Soluciones:

• Loop Out: cambia sats de Lightning por bitcoin on-chain con un swap submarino. Así vacías tu lado del canal y puedes recibir
• Pide que abran canales hacia ti: servicios como LN+ y Magma ofrecen liquidez de entrada
• Abre canales nuevos y después haz pagos a través de ellos: un canal que tú abres empieza con todo el saldo de tu lado. Por eso solo te da margen para recibir después de que gastes una parte
• Vacía canales: gasta o reequilibra para que salga saldo de tu lado

Canales desequilibrados que provocan fallos de enrutamiento

Si enrutas pagos de otras personas, el saldo de los canales afecta directamente a tus ingresos por enrutamiento. Un canal agotado en un sentido no puede reenviar pagos en ese sentido. Vigila la proporción de reenvíos que salen bien:

lncli fwdinghistory --start_time=-30d | jq '.forwarding_events | length'

Compara ese resultado con los intentos de reenvío fallidos que figuran en los registros para calcular la proporción de reenvíos que salen bien. Un nodo de enrutamiento en buen estado mantiene la mayoría de sus canales con un saldo local entre el 25 % y el 75 %. La guía de comisiones de Lightning explica cómo optimizar las comisiones y la liquidez.

Problemas de conectividad del nodo

Los problemas de conectividad impiden que tu nodo se comunique con otros nodos, propague anuncios y reenvíe pagos. A menudo son la causa oculta de lo que parece un problema de enrutamiento o liquidez.

Conectividad con Tor

Muchos nodos domésticos de Lightning usan Tor para proteger su privacidad. Tor añade latencia y puede provocar problemas de conexión ocasionales.

Problemas habituales de Tor:

• Tor no consigue establecer un circuito y eso impide la conexión con otros nodos
• Falla la publicación del descriptor del servicio onion y otros nodos no pueden llegar al tuyo
• La latencia alta agota el tiempo de espera al reenviar HTLC

Cómo comprobar el estado de Tor:

systemctl status tor
# Confirm that traffic through Tor works (the reply shows "IsTor": true)
torsocks curl -s https://check.torproject.org/api/ip

Si Tor está caído, reinícialo con sudo systemctl restart tor. Si los problemas persisten, detén Tor, borra solo los archivos de red que guarda en caché (los archivos cached-* de su directorio de datos, normalmente /var/lib/tor) y vuelve a iniciarlo para que los descargue otra vez. No borres todo el directorio. Un servicio onion configurado con HiddenServiceDir suele guardar allí su clave privada. Si borras esa clave, la dirección .onion del servicio cambia de forma permanente. Por defecto, LND guarda su propia clave onion en su propio directorio (v3_onion_private_key).

Modo híbrido: si tus requisitos de privacidad lo permiten, plantéate operar tu nodo en modo híbrido, por Tor y por la red pública (clearnet). Esto mejora mucho la conectividad y la fiabilidad de los pagos, y mantiene un punto de acceso Tor para los nodos que priorizan la privacidad.

Desconexiones de otros nodos

Las desconexiones frecuentes de determinados nodos provocan fallos de pago. Si se prolongan, pueden desencadenar cierres forzados.

lncli listpeers | jq '.peers[] | {pubkey: .pub_key, bytes_recv: .bytes_recv, ping_time: .ping_time, sat_sent: .sat_sent}'

Los tiempos altos de respuesta al ping (por encima de 5 segundos) indican problemas de conectividad. Si el otro nodo del canal responde siempre con mucha latencia o se queda sin conexión, quizá no merezca la pena mantener ese canal.

Problemas de base de datos y disco

La base de datos de canales de LND (channel.db) puede crecer mucho y causar problemas de rendimiento. Una base de datos dañada es uno de los peores escenarios para quien opera un nodo de Lightning.

# Check database size
ls -lh ~/.lnd/data/graph/mainnet/channel.db

# Check disk space
df -h /

Si channel.db supera 1 GB, plantéate compactarla en una parada programada. Mantén siempre actualizados tus archivos de copia de seguridad estática de canales (SCB, Static Channel Backup). Son la forma de recuperar los fondos si se daña la base de datos:

lncli exportchanbackup --all --output_file=/path/to/backup/channel-backup-$(date +%Y%m%d).backup

Consejos para prevenir fallos

Unas buenas prácticas operativas evitan la mayoría de los fallos de Lightning. Estos hábitos distinguen a los nodos fiables de los problemáticos.

Supervisión y alertas

• Supervisión del saldo: configura alertas para cuando el saldo local de cualquier canal baje del 10 % o supere el 90 %. Herramientas como ThunderHub, RTL (Ride The Lightning) y LNDmon ofrecen paneles y opciones de notificación.
• Supervisión del tiempo de actividad: usa una tarea sencilla de cron o un servicio externo para enviar un ping a tu nodo. Si el tiempo de actividad baja del 99 %, investiga los problemas de conectividad antes de que causen cierres forzados.
• Alertas de espacio en disco: si te quedas sin espacio, tu nodo se cierra de forma abrupta y la base de datos puede dañarse. Vigila el uso del disco y configura alertas al llegar al 80 % de capacidad.
• Copias de seguridad automáticas: usa un script para exportar cada día las copias de seguridad SCB a una ubicación fuera del nodo. Si falla el hardware de tu nodo, las copias de seguridad SCB permiten recuperar los fondos de todos los canales.

Selección de canales

• Conéctate a nodos bien mantenidos y con un tiempo de actividad alto. Consulta su historial en amboss.space o 1ML antes de abrir canales
• Evita abrir canales de menos de 500 000 sats. Los canales pequeños tienen una reserva obligatoria proporcionalmente alta y sirven de poco para enrutar pagos
• Elige nodos que usen distintas implementaciones y estén en regiones y posiciones distintas en la red
• Abre canales cuando las comisiones sean bajas para reducir al mínimo el costo on-chain de abrirlos

Mantenimiento periódico

• Actualiza pronto el software de tu nodo. Las versiones nuevas de LND, CLN y Eclair suelen corregir fallos de enrutamiento y mejorar la fiabilidad de los pagos
• Revisa y cierra los canales zombis cada mes para liberar fondos
• Reequilibra los canales antes de que empiecen a fallar los pagos
• Prueba al menos una vez el proceso de restauración. Una copia sin probar no es una copia de seguridad

Política de comisiones

Una mala configuración de las comisiones causa fallos de forma indirecta. Si cobras demasiado, nadie enruta pagos por tu nodo y pierdes presencia en el grafo. Si cobras demasiado poco, favoreces que se agote tu liquidez. Empieza con comisiones moderadas y ajústalas según el volumen real de reenvíos. La guía de comisiones explica en detalle cómo funciona esa economía.

Procedimientos de recuperación de emergencia

Cuando algo sale muy mal, conocer los pasos de recuperación evita errores por el pánico.

El nodo no arranca

1. Consulta primero los registros con journalctl -u lnd --since "1 hour ago" -n 200
2. Si el registro muestra Waiting for wallet encryption password, ejecuta lncli unlock e introduce la contraseña de tu billetera. LND la necesita después de cada reinicio. Que la billetera esté bloqueada no significa que esté dañada.
3. Si la base de datos está dañada, NO la borres. Cópiala a un lugar seguro y luego intenta repararla.
4. Si falla la reparación, restaura desde una copia de seguridad SCB. Esto fuerza el cierre de todos los canales, pero recupera los fondos.

La apertura de un canal se queda pendiente

La transacción de financiación del canal se difundió, pero aún no se ha confirmado. El canal sigue pendiente.

lncli pendingchannels | jq '.pending_open_channels'

Si la comisión de la transacción de financiación es demasiado baja, puedes subirla con CPFP (Child Pays For Parent) si tu versión de LND lo permite. Si no, espera a que la transacción se confirme o salga de la mempool.

Recuperación después de una desconexión larga

Si tu nodo estuvo sin conexión varios días, es posible que otros nodos hayan forzado el cierre de algunos canales. Después de reiniciarlo:

1. Deja que el nodo sincronice por completo la blockchain y el grafo de canales
2. Comprueba con lncli pendingchannels si hay canales con cierre forzado
3. Verifica con lncli walletbalance que tu saldo on-chain incluya los fondos recuperados
4. Vuelve a conectarte a los nodos restantes y comprueba qué canales siguen abiertos
5. Plantéate abrir canales nuevos para sustituir los que ya no tienes. Sigue los criterios de selección de los fundamentos de Lightning

Preguntas frecuentes

Mi pago falló con NO_ROUTE, pero el destino existe. ¿Qué pasa?

Tu nodo ve el destino en su grafo, pero no puede construir una ruta viable con liquidez suficiente. Por lo general, tu capacidad de salida es demasiado baja o está demasiado repartida. Prueba estas opciones: (1) reequilibra tu canal más grande para aumentar la capacidad de salida, (2) divide el pago con MPP si tu billetera lo admite o (3) abre un canal con un nodo bien conectado al entorno del destino.

Hubo un cierre forzado y mis fondos aparecen como «limbo_balance». ¿Los he perdido?

No. Ese saldo indica que los fondos están en una transacción on-chain con bloqueo temporal. Podrás gastarlos cuando venza el bloqueo. Si tú iniciaste el cierre forzado, ese es el plazo que fijó el otro nodo cuando se abrió el canal. Con los valores predeterminados de LND, son 144 bloques (cerca de un día) en canales de menos de unos 1,2 millones de sats y hasta 2016 bloques (unas dos semanas) en los más grandes. Si el otro nodo inició el cierre, puedes gastar tu saldo un bloque después de que se confirme el cierre. Consulta con lncli pendingchannels los bloques que faltan en blocks_til_maturity. Los fondos están a salvo, aunque no puedes acceder a ellos durante ese tiempo.

¿Cómo evito los cierres forzados?

Mantén un tiempo de actividad alto (99 % o más), actualiza el software del nodo, asegúrate de que la conexión a internet sea estable y vigila el espacio en disco. La mayoría de los cierres forzados ocurren porque un nodo lleva demasiado tiempo sin conexión. Una watchtower te protege si el otro nodo difunde estados antiguos del canal mientras el tuyo está sin conexión. El cierre forzado aún puede ocurrir.

¿Me conviene usar keysend o facturas normales?

Las facturas normales son más fiables porque el destino crea expresamente los parámetros del pago. Keysend, para pagos espontáneos, puede fallar si el destino no lo admite o si el enrutamiento necesita tomar decisiones a partir de sondeos. Para los pagos habituales, prefiere siempre las facturas. Keysend es útil para propinas y donaciones cuando pedir una factura resulta poco práctico.

Mi base de datos de canales es enorme. ¿Puedo compactarla de forma segura?

Sí, con la configuración del propio LND. Exporta una copia de seguridad SCB y comprueba que haya espacio libre en disco. Luego establece db.bolt.auto-compact=true en lnd.conf y reinicia LND. Al arrancar, LND compacta los archivos de su base de datos. LND escribe la base de datos compactada en un archivo temporal y solo sustituye el original cuando termina. Por eso, si la compactación falla, el original sigue en su sitio. La opción está desactivada por defecto porque la compactación necesita espacio adicional en disco mientras se ejecuta. Nunca compactes la base de datos con otra herramienta mientras LND esté en ejecución.

¿Qué diferencia hay entre un cierre cooperativo y uno forzado?

Un cierre cooperativo requiere que ambos nodos estén conectados y acuerden el reparto final del saldo. Genera una sola transacción on-chain sin bloqueos temporales. Los fondos se pueden gastar en cuanto se confirma. En un cierre forzado, un solo nodo difunde la transacción de compromiso. Eso activa bloqueos temporales y puede elevar las comisiones on-chain. Prefiere siempre el cierre cooperativo cuando sea posible.

Los pagos por un canal concreto siguen fallando. ¿Debería cerrarlo?

Comprueba primero si el problema es de liquidez (puedes reequilibrarla) o de fiabilidad del otro nodo del canal (un problema sistémico). Ejecuta lncli listchannels | jq '.channels[] | select(.chan_id=="CHANNEL_ID")' para comprobar el estado del canal, el tiempo de actividad y los HTLC pendientes. Si el otro nodo suele estar sin conexión o no responde, cerrar el canal y abrir otro con un nodo más fiable es mejor a largo plazo. Si el problema se limita al saldo, reequilibra el canal.