Inbound Liquidity es la capacidad de un nodo Lightning para recibir por los lados remotos de sus canales. Se basa en el remote balance del par, pero las reservas, los pagos pendientes, las reglas del canal y una ruta disponible limitan la recepción utilizable.
El remote balance pertenece al par y representa margen potencial para recibir; el local balance es su lado. Al recibir un pago, el valor pasa del lado remoto al local. Comprar capacidad de recepción no es, por tanto, un regalo de bitcoins ni ingresos ya obtenidos. [Lightning Labs — Managing liquidity]
En un canal simplificado de 1000000 sat con local balance de 800000 sat y remote balance de 200000 sat, el margen bruto de recepción es 200000 sat, no un millón. El ejemplo omite reservas, comisiones y HTLC pendientes. Financiar unilateralmente sin transferencia inicial crea sobre todo margen de salida; confirmar la apertura no invierte la dirección. [Lightning Labs — Managing liquidity] [BOLT 2 — Channel management]
BOLT 2 limita la adición de HTLC mediante reservas, importes mínimos, cantidad de HTLC simultáneos y su valor pendiente total. Los pagos pendientes pueden inmovilizar fondos temporalmente. Revise el importe disponible y los límites de cada canal; no reste una reserva universal de la suma de todos los saldos. [BOLT 2 — Channel management]
BOLT 7 publica parámetros direccionales channel_update, como comisiones y htlc_maximum_msat, no un saldo actual garantizado de toda la ruta. Un par desconectado o un cuello de botella anterior pueden detener el pago. La suma de saldos remotos no garantiza recibir ese importe desde un remitente concreto. [BOLT 7 — Routing gossip]
Un pago Lightning saliente reduce el local balance y aumenta el remote balance de los canales utilizados. Loop Out traslada valor Lightning a una salida on-chain y puede liberar margen de recepción; Loop In repone fondos de salida. No se crean bitcoins: incluya costes de enrutamiento, intercambio y on-chain, y el resultado de la operación. [Lightning Labs — Managing liquidity] [Lightning Loop — Direction and channel balances]
Un par puede financiar un canal hacia usted; en Lightning Pool un bid compra liquidez por tiempo limitado y un ask la ofrece. La duración se expresa en bloques. Pagar la prima y otras comisiones no convierte todo el saldo remoto en su propiedad ni garantiza disponibilidad permanente tras finalizar el acuerdo. [Lightning Labs — Managing liquidity] [Lightning Pool — Orders and leases]
Circular rebalancing envía por uno de sus canales y recibe por otro a través de la red. El canal de salida gana margen de recepción y el receptor lo consume. No crea capital nuevo y cuesta comisiones de enrutamiento; necesita una ruta utilizable y no resuelve por sí solo un nodo sin fondos en todos los lados remotos. [Lightning Labs — Managing liquidity]
Cobrar ingresos convierte continuamente saldos remotos en locales y puede agotar el margen para seguir recibiendo. Vigile canales utilizables, pagos pendientes, costes de reposición e importes previstos. Un intento fallido puede no ser visible en el nodo receptor; una factura emitida o una lectura antigua de capacidad no confirman el pago. [Lightning Labs — Merchant liquidity]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, Payment Channel, Lightning Routing, Submarine Swap, HTLC, Lightning Address. También enlazan con esta entrada Liquidez de Lightning, Lightning Routing, Lightning Address, Submarine Swap.