Inbound Liquidity

Petr tiene una cafetería y acepta pagos por Lightning Network. Su nodo, el programa que gestiona los pagos, muestra fondos, pero un cliente no consigue pagar. Una posible causa es la falta de liquidez entrante. Un canal de pago es un acuerdo entre nodos sobre cómo se reparte el bitcoin depositado. La parte de Petr se llama local balance y la de su contraparte, remote balance. Al recibir un pago, parte del valor del otro lado pasa a Petr. Para ello debe haber fondos que puedan pasar desde ese lado. El remote balance sigue perteneciendo a la contraparte: adquirir capacidad de recepción no es recibir bitcoin regalado ni ingresos ya ganados. [1] [6]

Imaginemos un canal con capacidad de 1000000 sat. Sat abrevia satoshi, una pequeña unidad de bitcoin. Petr tiene un local balance de 800000 sat y la contraparte un remote balance de 200000 sat. Por tanto, el margen bruto para recibir es de 200000 sat. Si Petr recibe 100000 sat, su lado sube a 900000 sat y a la contraparte le quedan 100000 sat. Petr ha ganado ese pago, pero le queda menos espacio para recibir. Para simplificar, el ejemplo omite reservas, comisiones y pagos pendientes llamados HTLC, explicados más adelante. Si Petr financia solo un canal nuevo, sin transferir inicialmente fondos a la contraparte, obtiene sobre todo capacidad de envío. Confirmar la apertura no invierte esa dirección. [1] [2]

En un día de buenas ventas, los fondos aumentan del lado de Petr mientras disminuye el margen entrante de los canales usados. Un saldo mayor puede ir acompañado de menor capacidad para recibir el siguiente pago. Con infraestructura propia hay que vigilar los canales utilizables, importes esperados, pagos en curso y coste de reponer liquidez. Algunas carteras hacen parte de este trabajo por el usuario, pero el mecanismo sigue existiendo. Petr quizá ni vea un intento fallido: el pago puede detenerse antes de llegar a su nodo. Una factura emitida o un dato antiguo de capacidad no confirman el cobro. [6]

Si Petr paga a un proveedor por Lightning, baja el local balance de los canales utilizados y aumenta su remote balance. Así puede abrir espacio para futuros cobros. Loop Out actúa de forma parecida: mediante un swap, un intercambio entre capas de pago, envía valor desde Lightning y recibe bitcoin en una dirección de la cadena. No hace falta cerrar los canales. Loop In hace lo contrario: transforma fondos de la cadena en saldo gastable por Lightning. Ninguna operación crea bitcoin. Al comparar el resultado hay que incluir comisiones de enrutamiento, del servicio de swap y de la transacción en la cadena, además de verificar que la operación terminó. [1] [4]

Otra opción es que la contraparte financie un canal hacia Petr. Él puede obtener capacidad de recepción sin que le regalen los fondos del otro lado. La documentación de Lightning Pool describe un mercado de esos acuerdos: bid solicita liquidez y ask ofrece proporcionarla. El alquiler tiene un plazo medido en bloques e incluye una prima y otras comisiones. Un bloque es un grupo de transacciones añadido a la cadena, el historial público de transacciones de Bitcoin. Por eso, el plazo sigue la llegada de bloques, no un número exacto de horas. No compra todo el saldo remoto. Tampoco significa que durante todo el plazo quede disponible el mismo importe: los pagos cambian el reparto. No se puede dar por sentada la disponibilidad permanente del canal una vez terminado el acuerdo. [1] [5]

Petr puede tener varios canales y necesitar margen entrante con otra contraparte. Circular rebalancing, o reequilibrio circular, envía su pago a la red por un canal y lo devuelve por otro canal suyo. El canal de salida gana margen entrante y el de llegada lo consume. Los fondos se trasladan entre sus lados de los canales; no aparece capital nuevo y se pagan comisiones de enrutamiento. Hace falta una ruta utilizable. Si no hay fondos en ninguno de los lados remotos de sus canales, no existe un canal por el que pueda regresar el pago. El reequilibrio circular por sí solo no lo resuelve. [1]

Parte de los fondos debe permanecer como reserva para el funcionamiento seguro del canal. Otros fondos pueden quedar comprometidos temporalmente en HTLC, compromisos de pago condicionados. El destinatario puede cobrarlos revelando un valor secreto del que se obtiene el hash de pago acordado, un dato que permite comprobar la condición. Si el pago falla, la parte que lo envió dispone de una vía para recuperar los fondos tras el plazo. BOLT 2, la especificación de gestión de canales, también limita el importe mínimo, el número de HTLC simultáneos y su valor total. Por eso puede no estar disponible todo el remote balance para otro pago. No basta con sumar los saldos remotos y restar una reserva universal: importan cada canal y su estado actual. [2]

Un pago suele atravesar varios nodos. Aunque Petr tenga margen para recibir, un tramo anterior puede estar desconectado o carecer de fondos. BOLT 7 describe los mensajes channel_update con los que los nodos anuncian condiciones de enrutamiento para un sentido del canal. Incluyen comisiones y htlc_maximum_msat, el máximo de un pago condicionado individual en msat, milésimas de satoshi. No prometen un saldo actualizado para toda la ruta. Por eso la suma del margen entrante de Petr no garantiza recibir esa cantidad de cualquier remitente concreto. La liquidez del destinatario es una parte necesaria de la solución, pero no la única. [3]