<p>Pierre answered my question on the <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002004.html" rel="nofollow noreferrer">lightning-dev list</a> and there is a <a href="https://github.com/lightningnetwork/lightning-rfc/pull/601" rel="nofollow noreferrer">pull request</a> 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 <code>nLocktime</code>. When the local node tries to spend the HTLC output, it has to explicitly set the <code>nLocktime</code> to <code>cltv_expiry</code> which prevents it from broadcasting the second-stage HTLC-timeout transaction until that time has reached.</p>

CC BY-SA 4.0
2019-06-05T16:54:57.180Z
2019-06-05T16:54:57.180Z
Ugam Kamat
<p>According to the BOLT #3 documentation, <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs" rel="nofollow noreferrer">the offered HTLC output</a> 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.</p>

<pre><code>1.  # To remote node with revocation key
2.  OP_DUP OP_HASH160 &lt;RIPEMD160(SHA256(revocationpubkey))&gt; OP_EQUAL
3.  OP_IF
4.      OP_CHECKSIG
5.  OP_ELSE
6.      &lt;remote_htlcpubkey&gt; 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 &lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG
10.      OP_ELSE
11.         # To remote node with preimage.
12.         OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
13.         OP_CHECKSIG
14.      OP_ENDIF
15. OP_ENDIF
</code></pre>

<p>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 <code>to_self_delay</code>. </p>

<p>Although the delay exists in the 2nd stage (<code>CSV</code> locked with <code>to_self_delay</code>), 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 <code>CSV</code>. The remote node will still forward the htlc because from its viewpoint it is still within the bounds of the <code>cltv_expiry</code> 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?</p>

<lightning-network><hash-time-locked-contract><lightning-rfc>
BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?
Ugam Kamat
# BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?

(Asked by: username_0 on 2019-06-01)

According to the BOLT #3 documentation, [the offered HTLC output](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs) 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?

**Tags:** lightning-network, hash-time-locked-contract, lightning-rfc


---

## 1 answers

### Answer by username_0 on 2019-06-05. Score: 0 | Accepted answer

Pierre answered my question on the [lightning-dev list](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002004.html) and there is a [pull request](https://github.com/lightningnetwork/lightning-rfc/pull/601) 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.


---

