<p>There are three ways in which that offered HTLC output can be redeemed: Revocation using the revocation public key (the example you mentioned), redeemed using a valid payment preimage or back to the local node after the timeout.</p>

<p><strong>Redeemed using a valid pre-image by remote node:</strong>  </p>

<ul>
<li>The stack starts at <code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt;</code></li>
<li>Since the <code>HASH160</code> of <code>&lt;payment_preimage&gt;</code> is not equal to the <code>HASH160</code> of <code>revocationpubkey</code>, the outer ELSE statement is triggered</li>
<li><code>&lt;remote_htlcpubkey&gt;</code> is pushed to the stack. Stack is now <code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;remote_htlcpubkey&gt;</code>.</li>
<li><code>OP_SWAP</code> is pushed to the stack, which swaps the top two items on the stack.</li>
<li>Stack is now <code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt;</code></li>
<li><code>OP_SIZE 32 OP_EQUAL</code> verifies that the <code>payment_preimage</code> is 32 bytes.</li>
<li>Since the <code>payment_preimage</code> is 32 bytes it will output 1. As a result <code>OP_NOTIF</code> will not be triggered, and hence <code>OP_ELSE</code> statement will be triggered.

<ul>
<li><code>OP_NOTIF</code> is triggered is the value on the stack is 0</li>
<li><code>OP_ELSE</code> is triggered if the preceding <code>OP_IF</code>, <code>OP_NOTIF</code> and <code>OP_ELSE</code> are not executed.</li>
</ul></li>
<li>The stack is still <code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt;</code></li>
<li>The <code>OP_HASH160</code> will hash the <code>paymentpreimage</code>. Since payment hash is <code>SHA256</code> of the payment preimage, we need to hash it with <code>RIPEMD160</code> so that it is equal to <code>HASH160</code> of the <code>paymentpreimage</code>.</li>
<li>If the hash matches, then the stack will be <code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; OP_CHECKSIG</code></li>
<li>If the signature matches the <code>remote_htlcpubkey</code> then 1 will be returned to the stack and this offered HTLC output is successfully spent by the remote node.</li>
</ul>

<p><strong>Redeemed after time-out by the local node:</strong>  </p>

<ul>
<li><p>To trigger the HTLC timeout condition, the local node will use the witness: <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; 0</code></p></li>
<li><p>The stack starts at <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; 0</code></p></li>
<li><p>Since the <code>HASH160</code> of <code>0</code> is not equal to the <code>HASH160</code> of <code>revocationpubkey</code>, the outer ELSE statement is triggered</p></li>
<li><p><code>&lt;remote_htlcpubkey&gt;</code> is pushed to the stack. Stack is now: <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; 0 &lt;remote_htlcpubkey&gt;</code></p></li>
<li><p><code>OP_SWAP</code> swaps the top two items on the stack. Stack is now: <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; &lt;remote_htlcpubkey&gt; 0</code></p></li>
<li><p>Since size of <code>0</code> is not 32 bytes it will return 0 on top of stack. This triggers the <code>OP_NOTIF</code> statement. Stack is still: <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; &lt;remote_htlcpubkey&gt; 0</code></p></li>
<li><p><code>OP_DROP</code> drops the top item on the stack which is <code>0</code>. Stack is now : <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; &lt;remote_htlcpubkey&gt;</code></p></li>
<li><p><code>2</code> is pushed to the stack. Stack is <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; &lt;remote_htlcpubkey&gt; 2</code></p></li>
<li><p><code>OP_SWAP</code> swaps the top two items on the stac. Stack is: <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; 2 &lt;remote_htlcpubkey&gt;</code></p></li>
<li><p><code>&lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG</code> is pushed to the stack. The stack is thus <code>0 &lt;remotehtlcsig&gt; &lt;localhtlcsig&gt; 2 &lt;remote_htlcpubkey&gt; &lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG</code>.</p></li>
<li><p>The above is a multisig output which can be spent only with valid signatures from the local and remote keys. These keys are exchanged when adding the HTLC. The output of the above transaction is sent to the local node using a <code>to_self_delay</code> using the time-out transactions.</p></li>
</ul>

CC BY-SA 4.0
2019-12-03T19:15:00.770Z
Thanks, this clears up a lot. A couple of questions though. 1) Why is the OP_SIZE 32 check needed? Isn't it enough to check that OP_HASH160 gives the right value? 2) Why is OP_NOTIF used instead of OP_IF (and of course switching what goes into OP_ELSE)?
Darius
CC BY-SA 4.0
2019-12-03T19:27:21.653Z
1) According to the BOLTs payment preimage HAS to be 32 bytes of data. Assume you generate an invoice with payment hash representing the SHA256 of a 40 byte data. Now when fulfilling the HTLC, you cannot send the 40 bytes of data and as a result would want to terminate the transaction on-chain. If the size counter was not there, the hash would be equal and you would get the bitcoins. But all the other nodes in the path will also have to terminate their channels on chain to get the funds as they won't be able to look get the preimage from the confirmed tx. The size keeps this behavior in check.
Ugam Kamat
CC BY-SA 4.0
2019-12-04T12:43:34.953Z
@Darius 2) The "Redeemed after time-out by local node case" that I mentioned in my answer is what triggers the OP_ELSE statement.
Ugam Kamat
CC BY-SA 4.0
2019-12-03T04:18:57.960Z
2019-12-03T07:47:35.563Z
2019-12-03T07:47:35.563Z
Ugam Kamat
<p>Check the <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">Script wiki</a> would be helpful. I once did this by hand, here's the process.</p>

<p>First, put the unlocking script on top of the locking script,</p>

<pre><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt;

# To remote node with revocation key
OP_DUP OP_HASH160 &lt;RIPEMD160(SHA256(revocationpubkey))&gt; OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    &lt;remote_htlcpubkey&gt; OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP &lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
</code></pre>

<p>If it helps, put them vertically,</p>

<pre><code>&lt;remotehtlcsig&gt;
&lt;payment_preimage&gt;
OP_DUP
OP_HASH160
&lt;RIPEMD160(SHA256(revocationpubkey))&gt;
OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
...
</code></pre>

<p><strong>Second, run them by hand.</strong> Keep in mind that, the instructions are read from top to bottom(or left to right), the stack grows as follows,</p>

<ol>
<li><code>&lt;remotehtlcsig&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; OP_DUP</code></li>
</ol>

<p><code>OP_DUP</code>, from wiki, duplicates the top stack item, so,</p>

<ol start="4">
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;payment_preimage&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;payment_preimage&gt; OP_HASH160</code></li>
</ol>

<p><code>OP_HASH160</code>, from wiki, The input is hashed twice: first with SHA-256 and then with RIPEMD-160, so we hash,</p>

<ol start="6">
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;payment_preimage_hash160&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;payment_preimage_hash160&gt; &lt;RIPEMD160(SHA256(revocationpubkey))&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;payment_preimage_hash160&gt; &lt;RIPEMD160(SHA256(revocationpubkey))&gt; OP_EQUAL</code></li>
</ol>

<p><code>OP_EQUAL</code>, from wiki, Returns 1 if the inputs are exactly equal, 0 otherwise. We check that <code>&lt;payment_preimage_hash160&gt;</code> != <code>&lt;RIPEMD160(SHA256(revocationpubkey))&gt;</code> and return 0,</p>

<ol start="9">
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; 0</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; OP_IF OP_CHECKSIG OP_ELSE</code></li>
</ol>

<p><code>OP_IF</code>, <code>OP_ELSE</code>, and <code>OP_NOTIF</code> are flow controls, from wiki, we will jump into the <code>OP_ELSE</code> clause, which is,</p>

<pre><code>...
OP_ELSE
    &lt;remote_htlcpubkey&gt; OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP &lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
</code></pre>

<p>Now we keep working on the stack,</p>

<ol start="11">
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;remote_htlcpubkey&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt; &lt;remote_htlcpubkey&gt; OP_SWAP</code>
<code>OP_SWAP</code>, from wiki, the top two items on the stack are swapped, so we swap <code>&lt;payment_preimage&gt;</code> and <code>&lt;remote_htlcpubkey&gt;</code>,</li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt; OP_SIZE</code></li>
</ol>

<p><code>OP_SIZE</code>, from wiki, pushes the string length of the top element of the stack (without popping it).</p>

<ol start="15">
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt; &lt;size of payment_preimage&gt;</code></li>
</ol>

<p>Notice that the size of a valid <code>&lt;payment_preimage&gt;</code> is 32,</p>

<ol start="16">
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt; &lt;size of payment_preimage&gt; 32</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt; &lt;size of payment_preimage&gt; 32 OP_EQUAL</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt; 1</code></li>
</ol>

<p>We have a 1 here, so we jump into the <code>OP_ELSE</code> section in the whole <code>OP_NOTIF ... OP_ENDIF</code>, to remind you, the script left is,</p>

<pre><code>...
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
</code></pre>

<ol start="19">
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt; 1 OP_NOTIF ... OP_ELSE</code></li>
</ol>

<p>Once jumped into the <code>OP_ELSE</code>, the rest is straightforward, step by step, we have,</p>

<ol start="20">
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;payment_preimage&gt; OP_HASH160</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;hash160 of payment_preimage&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;hash160 of payment_preimage&gt; &lt;RIPEMD160(payment_hash)&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; &lt;hash160 of payment_preimage&gt; &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt;</code></li>
<li><code>&lt;remotehtlcsig&gt; &lt;remote_htlcpubkey&gt; OP_CHECKSIG</code></li>
</ol>

<p>The final <code>OP_CHECKSIG</code> will check <code>&lt;remotehtlcsig&gt;</code> and <code>&lt;remote_htlcpubkey&gt;</code>, thus the HTLC will be spent via the unlocking script, <code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt;</code>.</p>

<p>The orders may not be strictly precise, but the general direction should be correct. Another tool is <a href="https://github.com/kallewoof/btcdeb" rel="nofollow noreferrer">Bitcoin Script Debugger</a>.
And yes, as pointed out by Ugam Kamat, there are three ways to redeem a HTCL.</p>

<p>Happy Lightning!</p>

CC BY-SA 4.0
2019-12-03T10:02:00.960Z
2019-12-03T10:02:00.960Z
yyforyongyu
<p>I'm looking at Bolt 3 in the Lightning rfc. My question is about how a HTLC is redeemed. Example HTLC script for reference:</p>

<pre><code># To remote node with revocation key
OP_DUP OP_HASH160 &lt;RIPEMD160(SHA256(revocationpubkey))&gt; OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    &lt;remote_htlcpubkey&gt; OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP &lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
</code></pre>

<p>My understanding is that it can be redeemed in two ways. The first way can be done if the revocation secret is known.</p>

<pre><code>&lt;revocation_sig&gt; &lt;revocationpubkey&gt;
</code></pre>

<p>revocationpubkey will produce the correct hash, OP_EQUAL will return "1", the script goes into OP_IF, and the revocation_sig will be valid for OP_CHECKSIG.</p>

<p>The second way involves </p>

<pre><code>&lt;remotehtlcsig&gt; &lt;payment_preimage&gt;
</code></pre>

<p>Can someone explain how this satisfies the script? For example, what OP_SWAP does or when it would go through OP_NOTIF/OP_ELSE?</p>

<lightning-network><script><hash-time-locked-contract>
Can someone explain how an HTLC is redeemed?
Darius
# Can someone explain how an HTLC is redeemed?

(Asked by: username_0 on 2019-12-03)

I'm looking at Bolt 3 in the Lightning rfc. My question is about how a HTLC is redeemed. Example HTLC script for reference:

```
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

```

My understanding is that it can be redeemed in two ways. The first way can be done if the revocation secret is known.

```
<revocation_sig> <revocationpubkey>

```

revocationpubkey will produce the correct hash, OP\_EQUAL will return "1", the script goes into OP\_IF, and the revocation\_sig will be valid for OP\_CHECKSIG.

The second way involves

```
<remotehtlcsig> <payment_preimage>

```

Can someone explain how this satisfies the script? For example, what OP\_SWAP does or when it would go through OP\_NOTIF/OP\_ELSE?

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


---

## 2 answers

### Answer by username_1 on 2019-12-03. Score: 3 | Accepted answer

There are three ways in which that offered HTLC output can be redeemed: Revocation using the revocation public key (the example you mentioned), redeemed using a valid payment preimage or back to the local node after the timeout.

**Redeemed using a valid pre-image by remote node:**

* The stack starts at `<remotehtlcsig> <payment_preimage>`
* Since the `HASH160` of `<payment_preimage>` is not equal to the `HASH160` of `revocationpubkey`, the outer ELSE statement is triggered
* `<remote_htlcpubkey>` is pushed to the stack. Stack is now `<remotehtlcsig> <payment_preimage> <remote_htlcpubkey>`.
* `OP_SWAP` is pushed to the stack, which swaps the top two items on the stack.
* Stack is now `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage>`
* `OP_SIZE 32 OP_EQUAL` verifies that the `payment_preimage` is 32 bytes.
* Since the `payment_preimage` is 32 bytes it will output 1. As a result `OP_NOTIF` will not be triggered, and hence `OP_ELSE` statement will be triggered.
  + `OP_NOTIF` is triggered is the value on the stack is 0
  + `OP_ELSE` is triggered if the preceding `OP_IF`, `OP_NOTIF` and `OP_ELSE` are not executed.
* The stack is still `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage>`
* The `OP_HASH160` will hash the `paymentpreimage`. Since payment hash is `SHA256` of the payment preimage, we need to hash it with `RIPEMD160` so that it is equal to `HASH160` of the `paymentpreimage`.
* If the hash matches, then the stack will be `<remotehtlcsig> <remote_htlcpubkey> OP_CHECKSIG`
* If the signature matches the `remote_htlcpubkey` then 1 will be returned to the stack and this offered HTLC output is successfully spent by the remote node.

**Redeemed after time-out by the local node:**

* To trigger the HTLC timeout condition, the local node will use the witness: `0 <remotehtlcsig> <localhtlcsig> 0`
* The stack starts at `0 <remotehtlcsig> <localhtlcsig> 0`
* Since the `HASH160` of `0` is not equal to the `HASH160` of `revocationpubkey`, the outer ELSE statement is triggered
* `<remote_htlcpubkey>` is pushed to the stack. Stack is now: `0 <remotehtlcsig> <localhtlcsig> 0 <remote_htlcpubkey>`
* `OP_SWAP` swaps the top two items on the stack. Stack is now: `0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0`
* Since size of `0` is not 32 bytes it will return 0 on top of stack. This triggers the `OP_NOTIF` statement. Stack is still: `0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0`
* `OP_DROP` drops the top item on the stack which is `0`. Stack is now : `0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey>`
* `2` is pushed to the stack. Stack is `0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 2`
* `OP_SWAP` swaps the top two items on the stac. Stack is: `0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey>`
* `<local_htlcpubkey> 2 OP_CHECKMULTISIG` is pushed to the stack. The stack is thus `0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey> <local_htlcpubkey> 2 OP_CHECKMULTISIG`.
* The above is a multisig output which can be spent only with valid signatures from the local and remote keys. These keys are exchanged when adding the HTLC. The output of the above transaction is sent to the local node using a `to_self_delay` using the time-out transactions.

> **Comments:**
> **username_0**: Thanks, this clears up a lot. A couple of questions though. 1) Why is the OP_SIZE 32 check needed? Isn't it enough to check that OP_HASH160 gives the right value? 2) Why is OP_NOTIF used instead of OP_IF (and of course switching what goes into OP_ELSE)?  
> **username_1**: 1) According to the BOLTs payment preimage HAS to be 32 bytes of data. Assume you generate an invoice with payment hash representing the SHA256 of a 40 byte data. Now when fulfilling the HTLC, you cannot send the 40 bytes of data and as a result would want to terminate the transaction on-chain. If the size counter was not there, the hash would be equal and you would get the bitcoins. But all the other nodes in the path will also have to terminate their channels on chain to get the funds as they won't be able to look get the preimage from the confirmed tx. The size keeps this behavior in check.  
> **username_1**: @username_0 2) The "Redeemed after time-out by local node case" that I mentioned in my answer is what triggers the OP_ELSE statement.  

---

### Answer by username_2 on 2019-12-03. Score: 2

Check the [Script wiki](https://en.bitcoin.it/wiki/Script) would be helpful. I once did this by hand, here's the process.

First, put the unlocking script on top of the locking script,

```
<remotehtlcsig> <payment_preimage>

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

```

If it helps, put them vertically,

```
<remotehtlcsig>
<payment_preimage>
OP_DUP
OP_HASH160
<RIPEMD160(SHA256(revocationpubkey))>
OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
...

```

**Second, run them by hand.** Keep in mind that, the instructions are read from top to bottom(or left to right), the stack grows as follows,

1. `<remotehtlcsig>`
2. `<remotehtlcsig> <payment_preimage>`
3. `<remotehtlcsig> <payment_preimage> OP_DUP`

`OP_DUP`, from wiki, duplicates the top stack item, so,

4. `<remotehtlcsig> <payment_preimage> <payment_preimage>`
5. `<remotehtlcsig> <payment_preimage> <payment_preimage> OP_HASH160`

`OP_HASH160`, from wiki, The input is hashed twice: first with SHA-256 and then with RIPEMD-160, so we hash,

6. `<remotehtlcsig> <payment_preimage> <payment_preimage_hash160>`
7. `<remotehtlcsig> <payment_preimage> <payment_preimage_hash160> <RIPEMD160(SHA256(revocationpubkey))>`
8. `<remotehtlcsig> <payment_preimage> <payment_preimage_hash160> <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL`

`OP_EQUAL`, from wiki, Returns 1 if the inputs are exactly equal, 0 otherwise. We check that `<payment_preimage_hash160>` != `<RIPEMD160(SHA256(revocationpubkey))>` and return 0,

9. `<remotehtlcsig> <payment_preimage> 0`
10. `<remotehtlcsig> <payment_preimage> OP_IF OP_CHECKSIG OP_ELSE`

`OP_IF`, `OP_ELSE`, and `OP_NOTIF` are flow controls, from wiki, we will jump into the `OP_ELSE` clause, which is,

```
...
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

```

Now we keep working on the stack,

11. `<remotehtlcsig> <payment_preimage> <remote_htlcpubkey>`
12. `<remotehtlcsig> <payment_preimage> <remote_htlcpubkey> OP_SWAP`
    `OP_SWAP`, from wiki, the top two items on the stack are swapped, so we swap `<payment_preimage>` and `<remote_htlcpubkey>`,
13. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage>`
14. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> OP_SIZE`

`OP_SIZE`, from wiki, pushes the string length of the top element of the stack (without popping it).

15. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> <size of payment_preimage>`

Notice that the size of a valid `<payment_preimage>` is 32,

16. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> <size of payment_preimage> 32`
17. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> <size of payment_preimage> 32 OP_EQUAL`
18. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> 1`

We have a 1 here, so we jump into the `OP_ELSE` section in the whole `OP_NOTIF ... OP_ENDIF`, to remind you, the script left is,

```
...
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

```

19. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> 1 OP_NOTIF ... OP_ELSE`

Once jumped into the `OP_ELSE`, the rest is straightforward, step by step, we have,

20. `<remotehtlcsig> <remote_htlcpubkey> <payment_preimage> OP_HASH160`
21. `<remotehtlcsig> <remote_htlcpubkey> <hash160 of payment_preimage>`
22. `<remotehtlcsig> <remote_htlcpubkey> <hash160 of payment_preimage> <RIPEMD160(payment_hash)>`
23. `<remotehtlcsig> <remote_htlcpubkey> <hash160 of payment_preimage> <RIPEMD160(payment_hash)> OP_EQUALVERIFY`
24. `<remotehtlcsig> <remote_htlcpubkey>`
25. `<remotehtlcsig> <remote_htlcpubkey> OP_CHECKSIG`

The final `OP_CHECKSIG` will check `<remotehtlcsig>` and `<remote_htlcpubkey>`, thus the HTLC will be spent via the unlocking script, `<remotehtlcsig> <payment_preimage>`.

The orders may not be strictly precise, but the general direction should be correct. Another tool is [Bitcoin Script Debugger](https://github.com/kallewoof/btcdeb).
And yes, as pointed out by username_1 username_1, there are three ways to redeem a HTCL.

Happy Lightning!


---

