0

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?

1 Answer 1

0

Pierre answered my question on the lightning-dev list and there is a pull request in order to make it more explicit. So the answer is that although the timeout is not addressed in the script, it is enforced in the HTLC-timeout transaction with an absolute timelock in the nLocktime. When the local node tries to spend the HTLC output, it has to explicitly set the nLocktime to cltv_expiry which prevents it from broadcasting the second-stage HTLC-timeout transaction until that time has reached.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.