Un contrato Hash con bloqueo de tiempo combina una condición de hash y de tiempo. En Lightning, cada salto reenvía un HTLC con importe, pago_hash y cltv_expiry; revelar una preimagen coincidente completa el pago hacia atrás a lo largo de la ruta, mientras que el tiempo de espera protege a los participantes si el cumplimiento no llega a tiempo. (payment_hash)
El remitente trabaja con hash de pago SHA-256. El destinatario completa el pago revelando una preimagen cuyo SHA-256 coincide exactamente con este hash. De este modo, el mismo secreto une el asentamiento atómico de múltiples lúpulos.
Cada HTLC tiene un vencimiento CLTV absoluto. Si la imagen previa no llega a tiempo, los nodos deben tener suficiente espacio para fallar la transacción o impulsar la cadena antes de que expiren sus compromisos ascendentes.
En el funcionamiento normal de Lightning, HTLC es un cambio de estado del canal a través de update_add_htlc y posterior cumplimiento o falla. Una transacción de bitcoin solo es necesaria cuando el canal se aplica en la cadena.
update_add_htlc contiene canal_id, id, cantidad_msat, pago_hash, cltv_expiry y cebolla_routing_packet. Peer verifica la política y crea un HTLC de seguimiento; no simplemente copia ciegamente el objeto de entrada.
El paquete Onion mostrará al salto solo la información necesaria para el siguiente paso. El nodo compara la cantidad y el CLTV saliente con la carga útil cifrada, para poder verificar las condiciones sin conocer la ruta completa.
El nodo de reenvío requiere una caducidad entrante posterior a la caducidad saliente. La diferencia da tiempo para reaccionar en la cadena si el downstream detecta una imagen previa o falla justo antes de la fecha límite.
BOLT #3 escribe salidas HTLC ofrecidas/recibidas en transacciones de compromiso con ramas exitosas y de tiempo de espera. Los scripts combinan hash, firmas y bloqueo de tiempo de tal manera que el resultado se puede aplicar incluso sin la cooperación de la contraparte.
Si la producción de HTLC cae por debajo del compromiso de umbral de polvo de la transacción después de contabilizar la tarifa, se puede eliminar de las salidas en cadena. Es por eso que BOLT #2 aborda la exposición al polvo como un riesgo real para el canal.
El pago se realiza sólo si cada salto acepta las condiciones y el destinatario revela la preimagen. La liquidez, los límites de tarifas, los límites de vencimiento y las políticas de enrutamiento pueden detener un pago mucho antes que la capa de consenso de Bitcoin.
Verifique update_add_htlc, montos entrantes/salientes y deltas de CLTV y supervise los mensajes de cumplimiento/fallo. Para la aplicación en cadena, decodifique la transacción de compromiso y la ruta de éxito/tiempo de espera del BOLT #3 de la salida HTLC.
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, Payment Channel, Timelock, Hash criptográfico, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. También enlazan con esta entrada Timelock, Payment Channel, Liquidez de Lightning, Lightning Routing.