2

I have a P2SH no segwit address (regtest) I create the redeem script with SHA256 and RIPEMD160 of my public key and prepend 0x0014

 ---------- Redeem Script --------- 
001407b01acbc2869d92912d50de6c7a6b9cb31487f0

 ---------- scriptPubKey --------- 
36e74f3c86af031ee34a4552c0d935d180db0a26

 ---------- ADDRESS P2SH️ --------- 
2MxFXaJvTozTJNZmd6E53wwFX7RnbDkGsGe

After that I want to create a transaction manually. I put redeem_script in scriptSig place holder and sign the transaction data.

After that I create the transaction with my signature and add even the redeem_script in scriptSig (like P2SH multi sig)

my final transaction data is:

0200000001f1838b3d294b74a1869140f538ba895b7aef81eab5e87206725ef1f868598a01000000005F47304402204a181d59fd36fb921d68596a4ae89ee6aef6980ab4a2f433ff28be4760744b76022027752d2a405c20aeda51038a8dccc3f2c0df1088fdebaee5f1eed9fad6ae086b0116001407b01acbc2869d92912d50de6c7a6b9cb31487f0ffffffff016036f829010000001976a9143dc3d9dc346b539125506ca681442d89c336813688ac00000000

I get this error:
mandatory-script-verify-flag-failed (Opcode missing or not understood) (code 16)
  • If you want to check the signature, then you have to have one of the CheckSig OP codes in your scripts. Right now all you are doing is pushing data to the stack without ever using them (apart from the 1 HASH160 OP). – Coding Enthusiast Mar 10 at 4:48
  • @CodingEnthusiast Yes, I want to understand how P2SH (no multisig) works. I want to understand When I create new address ("getnewaddress") I get P2SH by default (0.19.1) and I want to understand How it works the transaction. I don't want to create a custom script. – monkeyUser Mar 10 at 8:57
1

I want to understand how P2SH (no multisig) works

To understand that you first have to realize that despite what bitcoin wiki says bitcoin script evaluation is not as simple as running a Forth-like language. More precisely it is not 1) read 2) run. Instead it is more like 1) read 2) interpret (decide how to run) 3) construct the entire script based on 2 4) run. And it is not only "left to right" evaluation. Instead it always starts from looking at far right (PubkeyScript of the previous transaction ie. the tx being spent) then continues from left (which may be different now).

Focusing on P2SH, here are some examples (assuming reader knows what each OP code does, otherwise first take a look at the wiki link above):

  1. First fetch PubkeyScript of the transaction that is being spent and evaluate it to decide how to continue. Here we focus only on P2SH that has this pattern: OP_HASH160 <20 bytes push> OP_EQUAL. Because it is P2SH we continue like this:
  2. Start from SignatureScript and "run" only that script. It must contain at least one PushData operation at the end (the script can only be 1 push, or it could be other OPs ending with 1 mandatory push)
  3. Duplicate that mandatory push
  4. Run PubkeyScript with that duplicated item (pop1>hash>pushResult>push20>pop2>equalityCheck) if they were equal continue otherwise fail.
  5. Evaluate the mandatory push as a script (ie. RedeemScript) and decide how to continue.
  6. Here are different cases:
    6.1. RedeemScript = OP_0 <20 bytes push>
    6.2. RedeemScript = OP_0 <32 bytes push>
    6.3. RedeemScript = whatever else (I don't think there is any more special patterns other than above 2)

Case 6.3 is probably the easiest since it simply "runs" the RedeemScript. I say "whatever else" because as long as it is not a "special pattern" the evaluation is very simple and "normal". You can see this in all legacy multi-signature P2SH transactions easily found on the blockchain. But here is another example with a very simple RedeemScript to show what "whatever else" means: 463782617f0e6a69102530caa9ba2fe48f996128378af99ee437a22660afc5a7 that uses OP_2 OP_3 OP_ADD OP_5 OP_EQUAL as the RedeemScript (only 1 mandatory push).

Cases 6.1 and 6.2 are harder and a bit tricky because during the evaluation you have to "run" OP codes that don't even exist in the scripts! For example in case of 6.1 or the P2SH-P2WPKH you continue like this:

  1. Make sure there was no more than the single PushData in SignatureScript.
  2. Look among witnesses and expect 2 items, extract those
  3. Run a special OP_CheckSig (although it doesn't exist) for SegWit transactions. That means: first item in step 8 was a signature, the second one was a public key. Compute sigHash as descibed in BIP-143, run ECDSA.Verify(signature,sigHash,pubkey).

With 6.2 things get more complicated since there is now a WitnessScript which should be evaluated separately (a bit similar to RedeemScript).

| improve this answer | |
  • very nice answer, thanks a lot! there is a lot of stuff! I need to study more in order to create a clear question. thanks for your time – monkeyUser Mar 11 at 11:39
  • I'm reading BIP141. I created P2WPKH not P2SH right? – monkeyUser Mar 12 at 15:48
  • No, P2WPKH is directly paying to hash of a public key but P2SH (and the nested version P2SH-P2WPKH) pay to the hash of a script. – Coding Enthusiast Mar 13 at 7:35
1

Your redeemScript is incorrect. You need to push the public key to the stack by prepending it with its length. Otherwise the script interpreter will try to interpret the pubkey as opcodes, which is incorrect. Just putting the pubkey there does not work because the script interpreter does not know that those bytes are for a public key.

| improve this answer | |
  • you are right sorry, I pasted wrong code. Updated it. During generate my address I don't use segwit. – monkeyUser Mar 9 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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