HTLC

Anna quiere enviar 20 000 sat a Pavel por Lightning Network. Sat es la abreviatura de satoshi, la unidad más pequeña de bitcoin en la cadena. No comparten un canal de pago, pero ambos tienen una conexión adecuada a través de Eva. Un canal es un acuerdo entre dos participantes sobre el reparto de bitcoins, que puede actualizarse sin registrar cada pago en un bloque. Eva ofrece a Pavel 20 000 sat condicionados y Anna ofrece a Eva 20 010 sat; la diferencia de 10 sat es la comisión de Eva en este ejemplo simplificado. Son cambios de saldo enlazados en dos canales, no una misma moneda concreta que viaja por ellos. Pavel conoce un secreto que le permite cumplir su condición. Eva puede utilizar después ese mismo dato frente a Anna. No tiene que pagar primero a Pavel de forma irreversible basándose solo en su promesa. Las cifras ilustran el mecanismo; no son una comisión habitual ni recomendada. [1]

Pavel prepara un secreto aleatorio de 32 bytes para el pago, payment_preimage. SHA-256 calcula su payment_hash. Es fácil comprobar si el dato revelado produce la huella correcta; obtener un secreto bien elegido a partir de esa huella es, en la práctica, inviable. Una factura BOLT 11 habitual, una solicitud de pago Lightning, contiene el hash en el campo p, no la preimage. Cuando Pavel cumple el pago, el secreto vuelve por la ruta y enlaza los HTLC correspondientes. El payment_secret del campo s es diferente: ayuda al destinatario a procesar correctamente el pago y no sustituye a la preimage. Ninguno de esos datos es una Seed Phrase (las palabras para recuperar la cartera) ni la clave privada de la cartera. [1] [4]

Si ambos pagos tuvieran el mismo plazo, Pavel podría revelar el secreto tan tarde que Eva ya no pudiera reclamar el pago entrante. Por eso el HTLC que llega de Anna vence después del que Eva ofrece a Pavel. La diferencia, cltv_expiry_delta, proporciona un margen a Eva. También lo necesita si un participante deja de responder y hay que hacer cumplir el acuerdo mediante transacciones Bitcoin en la cadena. El margen se mide en bloques, no en minutos exactos, y debe contemplar retrasos y reorganizaciones. Su configuración segura depende del software y de las reglas del canal; un margen demasiado pequeño pone los fondos en riesgo. Una reorganización sustituye parte de la cadena por otra rama válida, lo que puede cambiar confirmaciones anteriores de transacciones. [1]

En Lightning, cltv_expiry es una altura de bloque: la posición del bloque en la cadena. No es un Unix timestamp (una fecha y hora expresadas como un número de segundos) ni la vigencia en segundos de una factura BOLT 11. Cuando se cumplen las condiciones temporales puede abrirse la vía timeout, para liquidar sin el secreto. Los fondos no se mueven solos: los nodos de Lightning, programas que gestionan los canales de pago, deben completar correctamente el cambio del canal o utilizar la transacción correspondiente en la cadena. Una preimage válida tampoco deja de funcionar automáticamente al vencer el plazo. Si la misma salida, un importe con reglas de gasto, aún no se ha gastado por otra vía, varias formas permitidas de gastarla pueden competir; ambas no pueden confirmarse en una misma cadena válida. Actuar a tiempo forma parte de la seguridad. [1] [4] [5]

HTLC enlaza condiciones; no consigue que cualquier importe atraviese cualquier ruta. Eva necesita fondos suficientes en el sentido de salida, es decir, liquidez, y espacio para otro HTLC pendiente. Los límites, las comisiones o un nodo no disponible pueden detener el pago. Mientras el intento pendiente no se resuelva correctamente, parte de los fondos puede quedar retenida. El estado de la cartera informa sobre el intento completo; no debe deducirse el resultado de un solo mensaje. Revelar la preimage no equivale a confirmar una transacción Bitcoin. Un pago Lightning ordinario y satisfactorio se liquida actualizando canales, sin registrar cada pago en un nuevo bloque. [1] [3]

Las secciones siguientes son una referencia técnica. El estado del canal indica a quién corresponde cada importe y qué HTLC siguen pendientes. Una commitment transaction es una transacción Bitcoin firmada que permite hacer cumplir ese estado en la cadena. update_add_htlc propone añadir un HTLC; update_fulfill_htlc comunica su cumplimiento y update_fail_htlc su fallo. Anunciar un cambio no basta. Mediante commitment_signed y revoke_and_ack se intercambian firmas del nuevo estado y datos que impiden utilizar con seguridad el anterior. Según BOLT 2, ambas partes deben haber aceptado irrevocablemente el cambio pertinente antes de que otro compromiso dependa de él. Ese acuerdo entre participantes no es una confirmación en un bloque. En cambio, financiar y eventualmente cerrar el canal sí requiere transacciones Bitcoin. [1]

Los campos son datos individuales de un mensaje. Un millisatoshi es una milésima de satoshi, una unidad contable dentro de Lightning; no es una fracción que pueda gastarse por separado en la cadena de Bitcoin. La base del mensaje update_add_htlc contiene channel_id, id, amount_msat, payment_hash, cltv_expiry y onion_routing_packet. amount_msat se expresa en millisatoshi. El nodo comprueba límites del canal, liquidez disponible y condiciones de reenvío; el HTLC saliente tiene parámetros propios. No debe ofrecer el HTLC correspondiente hasta que la incorporación del entrante quede comprometida de forma irrevocable según BOLT 2. [1]

Onion routing organiza las instrucciones de cada intermediario en capas cifradas separadas. Eva recibe lo necesario para su paso, no una lista legible de todos los participantes. El nodo descifra su propia capa onion y verifica su integridad. En una ruta ordinaria sin cegamiento compara amt_to_forward y outgoing_cltv_value con el importe entrante, la comisión y la diferencia temporal exigida. El paquete no le expone toda la ruta. Esto no excluye correlacionar tráfico ni deducir identidades por otros medios; onion routing no garantiza anonimato absoluto. [3]

Una salida es un importe con reglas de gasto, expresadas en el lenguaje Script. Offered y received indican si el participante ofrece o recibe el HTLC. La segunda etapa es una transacción posterior; CHECKSEQUENCEVERIFY (CSV) exige esperar desde la confirmación de la salida que se gasta. Una clave de revocación permite penalizar la publicación de un estado antiguo ya revocado. BOLT 3 distingue salidas offered y received y vías HTLC-success o HTLC-timeout. No basta con conocer un hash: se aplican las firmas, la preimage y las condiciones temporales pertinentes. La salida local de segunda etapa tiene un retraso CSV de to_self_delay; la clave de revocación correcta permite a la contraparte usar la rama de penalización sin ese retraso. El Script exacto depende del tipo de canal. [2] [6]

Trimming significa que un HTLC pequeño no llega a convertirse en una salida separada al llevar el estado del canal a la cadena. Dust designa esos importes pequeños. Dust exposure mide el valor total sujeto a esa limitación. Si el importe tras la comisión aplicable de segunda etapa queda por debajo de dust_limit_satoshis, la transacción de compromiso no crea una salida HTLC. Las reglas dependen del tipo negociado: option_anchors y zero_fee_commitments no tienen esa comisión de segunda etapa; zero_fee_commitments puede destinar el valor recortado a shared_anchor. Una salida inexistente no se puede reclamar por separado en cadena. La suma de estos HTLC constituye la exposición a dust. [2] [1]

La siguiente comprobación está destinada a operadores de nodos y desarrolladores. Decodificar convierte un registro en campos legibles; no envía nada ni demuestra por sí solo que todas las condiciones se cumplen. Compara amount_msat, payment_hash y cltv_expiry entrantes y salientes; verifica la preimage con SHA-256. Revisa también commitment_signed, revoke_and_ack y el estado final, no solo un mensaje fulfill/fail. Para la ejecución en cadena, decodifica la transacción de compromiso real, comprueba la existencia de la salida, la rama utilizada y HTLC-success/HTLC-timeout. Verifica firmas, condiciones temporales y confirmaciones; decodificar no demuestra por sí solo la validez. [1] [2]