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
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?