De acuerdo con la documentación de BOLT #3, la salida de HTLC ofrecida tiene el siguiente script que permite que el nodo remoto reclame los fondos con la imagen previa del pago y que el nodo local los reclame después de un tiempo de espera de HTLC.
1. # To remote node with revocation key
2. OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
3. OP_IF
4. OP_CHECKSIG
5. OP_ELSE
6. <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
7. OP_NOTIF
8. # To local node via HTLC-timeout transaction (timelocked).
9. OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
10. OP_ELSE
11. # To remote node with preimage.
12. OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
13. OP_CHECKSIG
14. OP_ENDIF
15. OP_ENDIF
Si ve el resultado que envía los fondos al nodo local (líneas 7-9), no está bloqueado en el tiempo en el script. Un nodo local después de firmar la transacción de compromiso, que incluye el HTLC que ofreció, puede transmitir la transacción de compromiso que reclama el dinero del tiempo de espera de HTLC (ya tiene las firmas) y paga a una dirección con to_self_delay.
Aunque el retraso existe en la segunda etapa ( CSVbloqueado con to_self_delay), nada me impide ofrecer un htlc a mi nodo par, firmar la transacción de compromiso actualizada y, un segundo después, transmitir la transacción de compromiso en la cadena principal y gastar el HTLC en una dirección bloqueada con CSV. El nodo remoto aún reenviará el htlc porque, desde su punto de vista, todavía está dentro de los límites cltv_expiryespecificados por BOLT. Ahora, cuando el nodo remoto obtiene la imagen previa, no tiene ninguna transacción con la que liquidar. ¿Dónde está la deficiencia en mi proceso de pensamiento y no es la caducidad del bloqueo de tiempo algo que debería incluirse en el script mismo?
Pierre respondió a mi pregunta sobre la lista lightning-dev y hay una solicitud de incorporación de cambios para que sea más explícito. Entonces, la respuesta es que, aunque el tiempo de espera no se aborda en el script, se aplica en la transacción de tiempo de espera de HTLC con un bloqueo de tiempo absoluto en el archivo nLocktime. Cuando el nodo local intenta gastar la salida de HTLC, tiene que establecer explícitamente en lo nLocktimeque cltv_expiryevita que transmita la transacción de tiempo de espera de HTLC de segunda etapa hasta que se alcance ese tiempo.