HTLC

¿Cómo puede Bruno reenviar tu pago sin poder quedárselo? Con un HTLC, un contrato con bloqueo por hash y por tiempo. Dice: «estos sats son tuyos si me enseñas la preimagen de este hash antes del bloque X; si no, vuelven a mí». Es un script de Bitcoin de verdad: si hiciera falta, se resuelve en la cadena.

Dani, que cobra, elige al azar una preimagen de 32 bytes, calcula su SHA-256 y lo pone en la factura como payment_hash. Tú creas un HTLC con Bruno con ese hash. Bruno crea otro con Carla, con el mismo hash y un poco menos de dinero (su comisión). Carla crea otro con Dani. Nadie puede cobrar sin la preimagen, y solo Dani la tiene.

Para cobrar, Dani revela la preimagen a Carla. Ahora Carla la conoce y la usa para cobrar a Bruno. Bruno la usa para cobrarte a ti. Pasa en segundos, sin tocar la cadena, y al final tú tienes la preimagen: la prueba de que Dani cobró.

Si Dani nunca la revela, nadie cobra y los HTLC caducan en orden inverso: primero el de Carla con Dani, luego el de Bruno con Carla y por último el tuyo con Bruno. Ese orden es la protección. Si Dani revelara la preimagen en el último momento, Carla aún tendría tiempo para cobrar a Bruno antes de que caducara su HTLC, y Bruno para cobrarte a ti.

Los HTLC tienen dos puntos débiles conocidos. Todos los saltos usan el mismo hash, así que dos nodos de la misma ruta pueden saber que es el mismo pago. Y alguien puede bloquear liquidez ajena enviando pagos que nunca completa. Se trabaja en mejoras, como sustituir el hash por puntos de la curva (PTLC), pero en 2026 los pagos siguen usando HTLC.