According to the BOLT #3 documentation, the offered HTLC output has the following script that allows the remote node to claim the funds with the payment pre-image and the local node to claim it after a HTLC timeout.
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
If you see the output that sends the funds to the local node (line 7-9), it is not timelocked in the script. A local node after signing the commitment transaction, which includes the HTLC he offered, can broadcast the commitment transaction that claims the money from the HTLC-timeout (he already has the signatures) and pays to an address with to_self_delay
.
Although the delay exists in the 2nd stage (CSV
locked with to_self_delay
), nothing stops me from offering a htlc to my peer node, sign the updated commitment transaction and a second later broadcast the commitment transaction on mainchain and spend the HTLC to an address locked with CSV
. The remote node will still forward the htlc because from its viewpoint it is still within the bounds of the cltv_expiry
as specified by BOLTs. Now, when the remote node gets the pre-image it doesn't have any transaction to settle with. Where is the shortcoming in my though process and isn't timelock expiry something that should be included in the script itself?