<p>Both <code>OP_CHECKSEQUENCEVERIFY</code>and <code>OP_CHECKLOCKTIMEVERIFY</code> were <code>OP_NOP</code> opcodes that were redefined to their current definitions via a softfork. The presence of an <code>OP_NOP</code> opcode does nothing on the stack (it neither pops the item nor verifies anything.)</p>

<p>Softforks can only constrict the definition, not expand them. When <code>OP_NOP</code> opcodes were re-defined to meet the new conditions of the TIMEOUT, the constriction was to make a transaction invalid if the TIMEOUT conditions are not met.</p>

<p>However, the property of <code>OP_NOP</code> to do nothing on the stack could not be changed as that would mean expanding the scope of it's definition. Thus the number (blocks or seconds) that precedes the <code>OP_CLTV</code> or <code>OP_CSV</code> continues to remain on the stack even after the verification. This number has to be dropped manually to make the script execute the next items correctly (like ECDSA signature verification), which is why we use the <code>OP_DROP</code> opcode.</p>

CC BY-SA 4.0
2019-12-17T11:23:24.377Z
2019-12-17T17:54:19.577Z
2019-12-17T17:54:19.577Z
Ugam Kamat
<p>The <code>TIMEOUTOP</code>, which is one of <code>OP_CHECKSEQUENCEVERIFY</code> or <code>OP_CHECKLOCKTIMEVERIFY</code>, will either:</p>

<ol>
<li>Terminate the script with an error if the TIMEOUT conditions are not met</li>
<li>Act as a NOP and leave the stack unchanged if the TIMEOUT conditions are met</li>
</ol>

<p>2 occurs if the timeout has been met, and leaves the top of the stack with the timeout delay value. <code>OP_DROP</code> removes this value from the top of the stack, allowing the regular p2pkh script to continue execution by consuming the rest of the stack.</p>

CC BY-SA 4.0
2019-12-16T23:43:06.490Z
2019-12-16T23:43:06.490Z
Raghav Sood
<p>From what I can tell <code>OP_DROP</code> is a method of storing non validation data in a tx (separate from using data after <code>OP_RETURN</code>).</p>
<p>However in this unlocking script described by bip199, the timeout block and timeout op are before the <code>OP_DROP</code>, meaning they would be dropped during validation? <code>OP_DROP</code> can't be describing what comes after because that should be the payment path validation - and because AFAIK bitcoin script is stack based.</p>
<p>What is the point of <code>OP_DROP</code>? How does it apply in the following script?</p>
<pre><code>OP_IF
    [HASHOP] &lt;digest&gt; OP_EQUALVERIFY OP_DUP OP_HASH160 &lt;seller pubkey hash&gt;            
OP_ELSE
    &lt;num&gt; [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 &lt;buyer pubkey hash&gt;
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
</code></pre>

<script><opcodes>
What is the purpose of OP_DROP
arshbot
# What is the purpose of OP_DROP

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

From what I can tell `OP_DROP` is a method of storing non validation data in a tx (separate from using data after `OP_RETURN`).

However in this unlocking script described by bip199, the timeout block and timeout op are before the `OP_DROP`, meaning they would be dropped during validation? `OP_DROP` can't be describing what comes after because that should be the payment path validation - and because AFAIK bitcoin script is stack based.

What is the point of `OP_DROP`? How does it apply in the following script?

```
OP_IF
    [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>            
OP_ELSE
    <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

```

**Tags:** script, opcodes


---

## 2 answers

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

Both `OP_CHECKSEQUENCEVERIFY`and `OP_CHECKLOCKTIMEVERIFY` were `OP_NOP` opcodes that were redefined to their current definitions via a softfork. The presence of an `OP_NOP` opcode does nothing on the stack (it neither pops the item nor verifies anything.)

Softforks can only constrict the definition, not expand them. When `OP_NOP` opcodes were re-defined to meet the new conditions of the TIMEOUT, the constriction was to make a transaction invalid if the TIMEOUT conditions are not met.

However, the property of `OP_NOP` to do nothing on the stack could not be changed as that would mean expanding the scope of it's definition. Thus the number (blocks or seconds) that precedes the `OP_CLTV` or `OP_CSV` continues to remain on the stack even after the verification. This number has to be dropped manually to make the script execute the next items correctly (like ECDSA signature verification), which is why we use the `OP_DROP` opcode.


---

### Answer by username_2 on 2019-12-16. Score: 3

The `TIMEOUTOP`, which is one of `OP_CHECKSEQUENCEVERIFY` or `OP_CHECKLOCKTIMEVERIFY`, will either:

1. Terminate the script with an error if the TIMEOUT conditions are not met
2. Act as a NOP and leave the stack unchanged if the TIMEOUT conditions are met

2 occurs if the timeout has been met, and leaves the top of the stack with the timeout delay value. `OP_DROP` removes this value from the top of the stack, allowing the regular p2pkh script to continue execution by consuming the rest of the stack.


---

