La liquidez de Lightning es la posibilidad de enviar o recibir dinero por un canal de pago. Un canal de pago comienza con fondos bloqueados en Bitcoin. Sus participantes pueden actualizar cómo se reparten esos fondos sin registrar cada pago individual en la cadena. La liquidez saliente procede de los fondos utilizables de tu lado; la entrante, de los del otro participante. La capacidad total incluye ambos lados, así que no indica por sí sola qué importe puede pasar en una dirección determinada.
Anna y Pavel tienen un canal con capacidad de 1.000.000 sat: un millón de satoshis, las unidades mínimas en la cadena de Bitcoin. Imaginemos un estado simplificado en el que Anna posee 800.000 sat y Pavel 200.000 sat. Para facilitar el ejemplo, dejamos aparte reservas, comisiones y pagos pendientes. Anna puede enviar dinero a Pavel desde su lado; solo puede recibir de él desde el suyo. Por tanto, Pavel no puede enviarle 300.000 sat por este canal, aunque su capacidad total sea de un millón. No ha desaparecido dinero: su distribución no permite ese pago. [1] [3]
La liquidez saliente es la cantidad utilizable para pagar desde tu lado. En el ejemplo parte del saldo de Anna de 800.000 sat, pero el máximo real suele ser menor por las reservas, comisiones y pagos pendientes. Si Anna paga a alguien distinto de Pavel, el primer paso sigue pasando por uno de sus canales. Un nodo es el programa que gestiona los canales y procesa los pagos de Lightning. Los nodos siguientes necesitan sus propios fondos para los pasos posteriores. Los bitcoin fuera de los canales no aumentan automáticamente su liquidez saliente; la cartera debe utilizar un mecanismo adecuado para llevar ese valor a Lightning. [1] [3]
La liquidez entrante es la cantidad que el otro participante puede enviarte. Si Anna abre un canal y posee casi todos sus fondos, tiene una buena base para enviar, pero poco margen para recibir. Crear otra solicitud de pago no cambia ese reparto. Necesita un canal cuyo otro participante tenga saldo utilizable. Algunas carteras lo consiguen mediante un proveedor de servicios y ocultan esa complejidad al usuario, a menudo a cambio de una comisión. La capacidad entrante no es dinero adicional que Anna ya posea: es la posibilidad de recibir un pago futuro. [1] [3] [5]
Anna paga ahora 100.000 sat a Pavel. En nuestro ejemplo simplificado, los saldos pasan a ser 700.000 sat para Anna y 300.000 sat para Pavel. La capacidad sigue siendo de 1.000.000 sat. Anna tiene menos margen para enviar y más para recibir de vuelta; a Pavel le ocurre lo contrario. Si la cartera tiene varios canales, cambian aquellos que el pago utilizó realmente. La dirección importa siempre. Una cifra de liquidez de la mañana puede no describir lo que se puede enviar por la tarde. [1] [3]
Un pago a un destinatario lejano recorre una sucesión de canales. Cada uno necesita suficiente liquidez utilizable en la dirección correcta, incluidas las cantidades destinadas a comisiones de pasos posteriores. Si un paso no puede transportar el pago, esa ruta falla aunque los demás canales tengan mucha capacidad. La cartera puede probar otra ruta o dividir el pago en varias partes si es compatible. Eso tampoco crea los fondos que faltan. El importe no es la única condición: los plazos también importan. Un HTLC es un pago condicional que puede completarse demostrando que se conoce un secreto concreto. Las reglas relacionadas con CLTV fijan plazos en bloques; la separación entre ellos da a los intermediarios tiempo para resolver el pago en la cadena de Bitcoin si se atasca el reenvío. [1] [2]
Un intermediario debe poder recibir por un canal y enviar el pago enlazado por otro. No basta con sumar saldos elevados. Si sus fondos están en su lado del canal equivocado, quizá no pueda utilizarlos en la ruta elegida. Para recibir necesita liquidez entrante en el primer canal; para reenviar, saliente en el segundo. Esos pasos se enlazan mediante condiciones HTLC: pagos cuyo cumplimiento depende de conocer un secreto concreto y de reglas temporales. El intermediario no se limita a confiar en la promesa de que el participante anterior le pagará después. [1] [3]
Los pagos recibidos y enviados cambian la liquidez de forma natural. Quien administra varios canales puede usar reequilibrio circular: enviar un pago por una ruta y recibirlo de vuelta por otra para desplazar saldos entre sus propios canales. Un swap intercambia fondos en la cadena por fondos en Lightning o al revés. Splicing permite modificar la financiación de un canal compatible sin el cierre y reapertura habituales. Otra opción es abrir otro canal. Estos métodos difieren en comisiones, tiempo, huella en la cadena, requisitos de confianza y riesgo de fallo. Ninguno crea dinero nuevo; elige según necesites enviar, recibir o ambas cosas. [1] [4]
Primero identifica si intentas enviar o recibir y si tu cartera y el otro nodo están conectados. En tu propio nodo, compara los saldos local y remoto de cada canal, las reservas, los pagos pendientes y las comisiones. Con una cartera gestionada, comprueba qué significa realmente la cifra de importe disponible. Un pago fallido no demuestra por sí solo que hayas perdido dinero: puede faltar liquidez en un paso, existir un límite o haber una interrupción temporal. Un pago de prueba menor solo comprueba ese importe en ese momento; no garantiza el paso de todos los pagos posteriores. [1] [3] [4]
Los operadores deben distinguir varios límites. Una salida de transacción indica una cantidad y las condiciones para gastarla. channel_reserve_satoshis indica fondos que deben permanecer como reserva. Otros pueden estar comprometidos en HTLC pendientes, pagos condicionales aún no completados. Los siguientes límites se aplican a los HTLC ofrecidos por el otro participante. max_htlc_value_in_flight_msat limita su valor total y max_accepted_htlcs su número; msat es una milésima de satoshi usada en la contabilidad de Lightning. Según el tipo de canal, también intervienen las comisiones de la commitment transaction que permite cerrarlo y, en su caso, anchor outputs: salidas especiales que permiten añadir una transacción posterior para aumentar la comisión del conjunto. Las reglas Dust determinan qué salidas son demasiado pequeñas para incluirse en esa transacción. Calcula el máximo disponible para la implementación y el tipo de canal concretos, no restando una reserva universal. [1] [6]
BOLT #7 describe los anuncios de canales y las reglas de reenvío. En un canal anunciado se pueden localizar en la cadena su salida de financiación y su capacidad. Eso no revela el reparto actual entre participantes. El emisor elige rutas con información propia, resultados anteriores e intentos de pago, no con una lista pública completa de saldos en tiempo real. Un explorador puede mostrar un canal grande sin demostrar que tu importe pase por él en la dirección correcta justo ahora. [2]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. También enlazan con esta entrada Payment Channel, Lightning Routing, Volatilidad, Capitalización de mercado.