Saltar al contenido
buybitcoinsmart

Glosario / Lightning y capa 2

Valor máximo de HTLC en tránsito

¿Qué es el valor máximo de HTLC en tránsito?
El valor máximo de HTLC en tránsito es el tope que cada par Lightning establece sobre el valor total de los pagos que la otra parte puede tener pendientes a la vez.

El tope es un único campo, max_htlc_value_in_flight_msat, que se acuerda al abrir un canal y se hace cumplir en cada pago posterior. Eclair trae un valor predeterminado de 5.000.000.000 milisatoshis o del 45 % de la capacidad del canal, el que sea menor, así que a un canal de 60 mBTC le corresponden 27 mBTC. Un pago Lightning grande puede fallarle en un canal que a simple vista tiene dinero suficiente, y a menudo esta es la razón.

Cómo funciona

El valor máximo de HTLC en tránsito se negocia, no se impone: cada lado declara el techo que quiere que el otro respete.

El campo viaja en open_channel (mensaje de tipo 32) y vuelve en accept_channel (tipo 33); los canales de financiación dual lo llevan en open_channel2 (64) y accept_channel2 (65). BOLT 2 lo describe como "a cap on total value of outstanding HTLCs offered by the remote node, which allows the local node to limit its exposure to HTLCs" (un tope sobre el valor total de los HTLC pendientes que ofrece el nodo remoto, que permite al nodo local limitar su exposición a los HTLC). Observe el sentido: el número que usted envía limita a su par, no a usted, así que un canal lleva dos topes que no tienen por qué coincidir.

En ambos extremos, la regla se hace cumplir sin contemplaciones. Un nodo que envía no debe añadir un pago si, sumado a lo que ya ha ofrecido, el valor total supera el tope del nodo remoto, y al nodo que recibe, si su par incumple la regla, se le indica que emita una advertencia y corte la conexión, o que haga fallar el canal directamente. Su campo hermano, max_accepted_htlcs, cuenta los pagos pendientes en lugar de medirlos, y la especificación le pone un tope estricto de 483, que baja a 114 cuando el canal usa compromisos sin comisión. El tope de valor no tiene un techo equivalente: es pura política del nodo, y la única salvaguarda de la especificación es que el nodo que recibe puede rechazar un canal cuya cifra parezca demasiado pequeña.

El dinero en reposo no se ve afectado. Un canal puede tener muchas veces el tope en saldo liquidado, porque el límite solo cuenta los pagos en movimiento, los que habría que desenredar on-chain si el canal se cerrara mal.

Dónde aparece

El valor máximo de HTLC en tránsito nunca aparece en el grafo público de Lightning, así que ningún explorador de canales se lo mostrará.

Se filtra de una única manera concreta. BOLT 7 exige que un nodo que publica un mensaje channel_update ponga en el campo htlc_maximum_msat, el pago individual más grande que reenviará, un valor no superior al max_htlc_value_in_flight_msat que recibió de su par. Así, un número privado le pone un techo firme a uno público: un par prudente obliga a bajar la cifra anunciada, aunque un nodo es libre de anunciar menos de lo que su par permite.

Los valores predeterminados difieren entre implementaciones lo suficiente como para importar. La configuración de referencia de Eclair pone max-htlc-value-in-flight-msat en 5.000.000.000 y max-htlc-value-in-flight-percent en 45, aplica el que sea menor e indica que el ajuste es por sentido, así que los dos sentidos juntos pueden llegar al doble de la cifra. Eclair también pone max-accepted-htlcs en 30, mientras que la configuración de ejemplo de LND trae default-remote-max-htlcs en 483, el máximo de la especificación. Dos operadores con los valores predeterminados intactos pueden discrepar en un factor de dieciséis solo en el recuento.

Para un comprador, el síntoma es un pago que falla sin explicación. Dividir el monto en partes no lo salva cuando las partes toman el mismo canal, porque el tope las suma. ACINQ, que publica esos valores predeterminados de eclair, también ofrece Phoenix, la billetera para teléfono reseñada en este sitio; cualquier billetera que abra canales por usted elige estos números en su nombre.

Valor máximo de HTLC en tránsito frente a capacidad del canal

La capacidad del canal es el monto bloqueado en la salida de financiación de un canal, mientras que el valor máximo de HTLC en tránsito determina qué parte de ese monto puede estar a mitad de un pago en un momento dado.

La capacidad es un dato público, determinado por la transacción de financiación y anunciado a toda la red. El tope en tránsito es privado, se intercambia solo entre los dos pares, se establece por separado para cada sentido y se elige por política y no por aritmética. El valor predeterminado porcentual de Eclair hace concreta la diferencia: el 45 % se aplica a cada sentido por separado, así que más de la mitad de la capacidad tiene vedado moverse en un solo sentido a la vez. Un canal que muestra mucho espacio de su lado puede aun así rechazar un pago, y la cifra que lo rechazó es una que usted no puede consultar.

No confundir con

Preguntas frecuentes

¿Por qué falló mi pago Lightning si el canal tenía saldo suficiente?

A menudo porque los pagos ya pendientes en ese canal más el nuevo superarían max_htlc_value_in_flight_msat, el tope que su par estableció cuando se abrió el canal. El tope limita el dinero en movimiento, no el dinero en reposo, así que un canal puede mostrar fondos de sobra y aun así rechazar su pago.

¿Es el valor máximo de HTLC en tránsito lo mismo que max_accepted_htlcs?

No, uno pone un tope al valor y el otro, al número de HTLC. BOLT 2 limita max_accepted_htlcs a 483, o a 114 en los canales que usan compromisos sin comisión, mientras que el tope de valor no tiene techo en la especificación y lo establece únicamente la política del nodo.

¿Dividir un pago en partes permite esquivar el tope?

No cuando las partes viajan por el mismo canal, porque el tope suma todos los pagos pendientes en ese sentido. Repartir las partes entre canales distintos puede ayudar, ya que cada canal tiene su propio límite, negociado por separado.

Para seguir leyendo

Términos relacionados

Más en la sección Lightning y capa 2

Leer esta página en inglés