I'm studying P2SH-P2WPKH and when I create the signed transaction I can see this stack (using btcdeb)

script                                   |                                                             stack 
OP_DUP                                   | Public Key
OP_HASH160                               | Signature
3ecfc6b4....a49                          | 
OP_EQUALVERIFY                           | 
OP_CHECKSIG                              | 

The question is Where and When I push OP_DUP e OP_CHECKSIG? I don't find anything inside Bitcoin code in GitHub, maybe during signrawtransactionwithkey?

I understand that the stack contains the


like P2PKH, but I don't understand why are inside the stack.

It's my UTXO and I don't find 1a83d46422201593cb8f42f44a22a29e86ad652f inside my stack.

  "asm": "OP_HASH160 1a83d46422201593cb8f42f44a22a29e86ad652f OP_EQUAL",
  "hex": "a9141a83d46422201593cb8f42f44a22a29e86ad652f87",
  "reqSigs": 1,
  "type": "scripthash",
  "addresses": [

UPDATE I don't find the code inside Github, but maybe thanks to the witness program (<0 <20-byte-key-hash>>) the software is triggered and create the stack with P2PKH. For the older node is ANYONE_CAN_SPEND, for newer node check if hash160 (pubkey) == pubkeyhash and then check the signature.

In that case When the UTXO is involve only for TXID and Amount, not for validation (scriptPubKey) like P2SH and P2PKH.

  • 1
    I think!! Your script a ScriptPubKey (unlock script) and the operator OP_DUP create a dump of the stack whet the ScriptSig (locked script) was execute and copy on a different stack. Why this? because in past the bitcoin worked on the single stack and it was corrupted. the OP_DUP is used because now bitcoin uses more stack to verify a script. I'm only a bitcoin student, not take my answer how true, but test this or wait for a possible answer from bitcoin-dev. Apr 11, 2020 at 17:11
  • Thanks, Do you have some documentation about it?
    – monkeyUser
    Apr 11, 2020 at 17:13
  • OP_DUP Duplicates the top stack item, not the entire stack
    – monkeyUser
    Apr 11, 2020 at 17:15
  • I don't know where you can found the documentation. about the operator OP_DUMP if you think, the entry stack is the ScriptSig. Maybe I have the wrong information. I only added an idea. Apr 11, 2020 at 17:17
  • no, it's the public key
    – monkeyUser
    Apr 11, 2020 at 17:19

1 Answer 1


The question is Where and When I push OP_DUP e OP_CHECKSIG?

You don't. Neither the transaction creating the output or the transaction spending it explicitly contain these instructions.

When verifying a P2WPKH spend (which means either the scriptPubKey or the P2SH redeemScript is exactly OP_0 <20-byte hash>), special logic is triggered which verifies the witness stack against the script OP_DUP OP_HASH160 <20-byte-hash> OP_EQUALVERIFY OP_CHECKSIG.

See the examples in BIP 141 for more information.

  • In that case I get only VOUT Amount and Txid from UTXO. Why I need to store informations in asm (and hex) of UTXO scriptPubKey?
    – monkeyUser
    Apr 11, 2020 at 23:25
  • I don't understand your question. What are you trying to accomplish? Apr 11, 2020 at 23:28
  • In P2SH and P2PKH, I need to get informations from ScriptPubKey to unlock the transaction. In P2SH-P2WPKH I don't care about scriptPubKey a9141a83d46422201593cb8f42f44a22a29e86ad652f87 to unlock the transaction
    – monkeyUser
    Apr 12, 2020 at 9:55
  • I know that 1a83d46422201593cb8f42f44a22a29e86ad652f is hash160 of redeem script. Maybe first of all check if redeem script hash160 is equal to scriptPubKey to satisfy backwards? And "duplicate" the stack like "classic" P2SH, where older node check only this condition and "see" the transaction ANYONE_CAN_SPEND?
    – monkeyUser
    Apr 12, 2020 at 10:33
  • 1
    I have no idea what you're talking about. In all of P2SH, P2WSH, and P2SH-P2WSH, no actual locking code is in the scriptPubKey (and in P2SH-P2WSH not in redeemScript either). They all just have some fixed magical formula in scriptPubKey that says "look elsewhere for the script". Apr 12, 2020 at 18:11

Your Answer

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

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