I created this 2-of-2 multi-signature address for testnet following the instructions on the book Programming Bitcoin. I tried to spend the funds in this address following the standard forms (OP_HASH160 1060f2fd6058cd100fe4e485455badf453bd63e1 OP_EQUAL) Everything passes the verification tests in the code, but when I try to broadcast my transaction it never gets mined or it is rejected with ERROR: 64: NON-MANDATORY-SCRIPT-VERIFY-FLAG (EXTRA ITEMS LEFT ON STACK AFTER EXECUTION).

here is my raw transaction:


I have only one input, and I am spending it all. The commands for the script signature for this input are built following the standard (OP_0, Sig1, Sig2, Redeem_script):





which are encoded in the transactions as:


My redeem script follows the standard (OP_M, pubkey1, pubkey2, OP_N, OP_CHECKMULTISIG):

OP_2 03e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e4 031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee OP_2 OP_CHECKMULTISIG

The input I am trying to spend is under the transaction:


By looking at the error, it seems like my public_key_script and my redeem_script are not consuming all the data in the stack, but I have checked everything, and I can't find what it is. HELP!

Ps: I do not think this is a relevant detail, but the input of the transaction was sent by one of the two public keys that generated the multi-signature address. Just trying to be thorough.

1 Answer 1


Your redeemScript contains the length byte for it. The redeemScript is really just a script without any prepended length byte. So for your script, it is


Note how it begins with 52 and not 47.

How P2SH works is that it takes the top stack element and executes it as a script. Since you began your redeemScript with 47, this script just pushes the next 0x47 bytes to the stack instead of executing the multisig that you wanted.

It is perfectly valid to do this, even if that is not what you intended. A non-empty and non-false stack means that the script succeeded, so your transaction is consensus valid and could be included in a block. It is not standard because you have more than one stack element left on the stack after script execution, which is why this does not relay.

The correct version of your transaction is


but this is not valid. The redeemScript no longer matches the scriptPubKey of the output being spent (script execution stops here). But the signatures would also be invalid because they have signed a different redeemScript.

Because your transaction does not require any signatures, just pushing the script (that does nothing) that matches the hash in your scriptPubKey,


is a valid, relayable, transaction spending your output.

  • Thanks a lot! I overlooked the length of the hash. Now I have to fix my code to make it work. This error means I have the wrong multisignature address as well, so I'll have to start over . I will definitely let you know how it goes. I still don't understand, however, how you were able to build a valid transaction without the 2 signatures, and only using the redeem script? Is it because I am using 2-of-2? This means that basically everybody could spend the funds in this address by only knowing the redeem script which is now public due to this tx. Feb 17, 2020 at 19:16
  • I just fixed my code, and it worked! Thanks a lot man!! I'm still wondering why you say "Because your transaction does not require any signatures, just pushing the script (that does nothing) that matches the hash in your scriptPubKey". I thought I had set it up to require 2 signatures out of 2 possible. However, your transaction without these signatures got broadcasted with no sweat. What exactly am I missing to actually make this address a truly multi-signature address that will require 2 of the 2 signatures? Feb 17, 2020 at 21:23
  • Oh! is it just because I have that extra OP_72 at the beginning of the script that makes it non-standard and therefore makes it totally useless? So if I have no extra OP_72 my address will actually require both of the signatures to transact? Feb 17, 2020 at 21:53
  • 1
    Yes, it's because of the OP_72. The script that is actually run is just "push 72 bytes onto the stack" and those 72 bytes are the script that you wanted to run with the checkmultisig. But because that is never executed, no signature checks ever take place.
    – Ava Chow
    Feb 17, 2020 at 22:50

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.