Glossary / Developer reference
OP_DUP
- Definition
- OP_DUP copies the top item on the stack so it can be used twice, which is why the standard pay-to-public-key-hash script can both hash your public key and verify against it.
One byte, 0x76, and one job. Bitcoin Script has no variables, only a stack, so an item consumed by one instruction is gone before the next one runs, and duplication is the only way to reuse it. It is the first of the four working opcodes in the 25-byte script that guarded almost every bitcoin address beginning with 1.
How it works
Duplication is necessary because verification needs the same public key for two incompatible purposes. The output only committed to a hash, so the key has to be hashed and compared to prove it is the right key. Signature checking then needs the key itself, which the comparison would have consumed.
Follow a legacy spend through. The spender's data lands on the stack as a signature with a public key above it. OP_DUP makes a second copy of the key. OP_HASH160 replaces the copy with its 20-byte digest. The output pushes the committed 20 bytes, OP_EQUALVERIFY consumes both and aborts the whole script on any mismatch, and OP_CHECKSIG is left facing the original key and the signature, exactly what it needs. Five steps, no branching, no loops, and a fixed cost every time.
The opcode counts against two ceilings without doing anything expensive. It is one of the 201 working instructions a pre-Taproot script may contain, and the copy it makes counts toward the limit of 1,000 items across the stacks. Neither matters for a single-key spend and both matter in a script that duplicates inside a loop-free chain of conditions.
Where you see it
Look at any transaction spending an address that starts with 1 and the output script begins with OP_DUP. Explorers print it as the first token of the assembly.
More interesting is where it runs without appearing. A native SegWit single-key output contains no logic at all, only a version byte and a 20-byte hash, but BIP-141 tells the node to build the classic template from that hash and execute it anyway. So the opcode still fires on every P2WPKH spend on the network and appears nowhere in the block. You get the behaviour without paying the four weight units the byte used to cost.
Script hash outputs and Taproot key-path spends skip it entirely. A P2SH output compares a hash directly, and a Taproot key spend verifies a signature against the output key with no script involved. This is the smallest possible illustration of what SegWit and Taproot really did: not new capabilities so much as the same checks arranged so the chain has to carry fewer bytes to get them.