<p>After some additional research and helpful information found here, I was able to conclude the following:</p>

<p>Transactions encoded on 0.12.X bitcoin and then broadcast on 0.15 bitcoin may encounter "mandatory-script-verify-flag-failed (signature must be zero for failed check(multi)sig operation)"</p>

<p>This problem can be solved by doing the following:
Signing your 0.12.X raw transaction with a 0.15 signature. I cannot pinpoint the exact issue, however I was able to encode the raw transaction on 0.12.X and the sign it on 0.15 and successfully broadcast it. This information may be useful if someone is trying to figure out what parts of their signing process need to be refactored / updated.</p>

CC BY-SA 4.0
2018-09-01T14:13:24.830Z
2018-09-01T14:13:24.830Z
xagau
<p>I forked the openwallet-android so that I could add my coin - (placeholders) placeh.io.</p>

<p>The openwallet-android connects to electrumx server. I am able to get my chain to load correctly in electrumx server. The openwallet correctly reads the balance from the address / inputs and you can see your balance through the wallet.</p>

<p>However, when I try to broadcast a transaction I am getting the message:</p>

<p><code>"mandatory-script-verify-flag-failed (signature must be zero for failed check(multi)sig operation)"</code></p>

<p>From placehd/placeh network.</p>

<p>Here is some additional information, this is the rawtransaction that is being published. If I try to send the raw transaction in the placeh-cli client, it will not succeed and produces the same error when done manually</p>

<p>Raw Transaction:</p>

<pre><code>placeh-cli decoderawtransaction 

01000000017477f59250a8d8a7d94ba5dcc196222c0b6c92849cad210735b4380b24c03b13010000006a473044022053b17723e8a90846fc341006f5f63d5776df619f33cec82d8065e836508672c6022036298087c2f37c3002c4897b74e7de6af8c608c89cbcef07ada9c5551c85f2810121031dc78b8c254649e204b81641f70497980ca6b5574f837001c962930580d1372dffffffff02c00e1602000000001976a914a117ed0f4e2afe1e1b8d2b0253408a7830f2b55688ac0093e651020000001976a914c472af380586ed1638686731cc1eda3c60363ec788ac00000000
{
  "txid": "de045f2220d0b9f34060336c9ed3badc7c22741fec3aa1d87ff24264c3c1fb5e",
  "hash": "de045f2220d0b9f34060336c9ed3badc7c22741fec3aa1d87ff24264c3c1fb5e",
  "version": 1,
  "size": 225,
  "vsize": 225,
  "locktime": 0,
  "vin": [
    {
      "txid": "133bc0240b38b4350721ad9c84926c0b2c2296c1dca54bd9a7d8a85092f57774",
      "vout": 1,
      "scriptSig": {
        "asm": "3044022053b17723e8a90846fc341006f5f63d5776df619f33cec82d8065e836508672c6022036298087c2f37c3002c4897b74e7de6af8c608c89cbcef07ada9c5551c85f281[ALL] 031dc78b8c254649e204b81641f70497980ca6b5574f837001c962930580d1372d",
        "hex": "473044022053b17723e8a90846fc341006f5f63d5776df619f33cec82d8065e836508672c6022036298087c2f37c3002c4897b74e7de6af8c608c89cbcef07ada9c5551c85f2810121031dc78b8c254649e204b81641f70497980ca6b5574f837001c962930580d1372d"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.35000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 a117ed0f4e2afe1e1b8d2b0253408a7830f2b556 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a117ed0f4e2afe1e1b8d2b0253408a7830f2b55688ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FLWtv6SuocTFMozTZvdZAhroJLehVjLKhs"
        ]
      }
    },
    {
      "value": 99.64000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 c472af380586ed1638686731cc1eda3c60363ec7 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914c472af380586ed1638686731cc1eda3c60363ec788ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FPjqHpEzdYAbxVG2acxz8GWGAPmJsWj6oP"
        ]
      }
    }
  ]
}
</code></pre>

<p>I believe this may have something to do with the way that the openwallet is constructing the raw transaction. I would like to update the libraries so that it will be able to broadcast the transaction correctly.</p>

CC BY-SA 4.0
2018-08-09T19:28:41.957Z
This means the signature was invalid, perhaps the signature is not being created correctly, maybe the transaction data it is signing doesn't match, or the private key(s) used isn't able to spend the previous output.
JBaczuk
CC BY-SA 4.0
2018-08-09T19:33:50.067Z
JBaczuk: Do you have any suggestions about how I might go about fixing this issue? Transactions created and signed in placeh-qt seem to work fine.
xagau
CC BY-SA 4.0
2018-08-09T19:34:23.873Z
Without (a) the transaction output being spent and (b) the consensus rules of your altcoin, there is no way to answer this.
Pieter Wuille
CC BY-SA 4.0
2018-08-09T19:36:23.457Z
Thanks Pieter, I posted the altcoin source here, it is a "fairly recent" fork of bitcoin core. https://github.com/xagau/placeh
xagau
CC BY-SA 4.0
2018-08-09T19:59:52.013Z
Your actual signature is valid (at least according to my bitcoin script vm). Perhaps you're running into something similar to [this](https://github.com/bitcoin/bitcoin/issues/11891). Are you sure openwallet is handling the amounts correctly when signing?
Raghav Sood
CC BY-SA 4.0
2018-08-09T20:07:22.397Z
@RaghavSood where are you getting the input scriptPubKey to validate it?
JBaczuk
CC BY-SA 4.0
2018-08-09T20:09:21.947Z
Raghav, I am not certain. I don't know how long ago openwallet was "actually updated" but it appears to work with Bitcoin, although I have not sent any real bitcoin into it to test. The openwallet fork is over at https://github.com/xagau/openwallet-android. Unfortunately I have to solve this basic plumbing problem before I can try to build on top and its just a bit out of my league. I saw comments about the vout amounts having to add up to an exact amount including the fee but I am a bit unsure.
xagau
CC BY-SA 4.0
2018-08-09T20:10:16.207Z
@JBaczuk Just decoded the address off the explorer linked on the coin site to get the HASH160 (`40840b34365502f6fa5f066b137cf5081b7be8f8`), then just added the opcodes back myself to get `76a91440840b34365502f6fa5f066b137cf5081b7be8f888ac`, which is a standard p2pkh script
Raghav Sood
CC BY-SA 4.0
2018-08-09T20:11:45.170Z
@xagau Your amounts under decoderawtransaction seem correct. It's possible that the amounts aren't taken correctly during the signing process, so the amounts in your vout in the raw tx differ from what was signed. This is pure speculation though, based only on the fact that there is an open issue for it in bitcoin core, and that the signature itself is valid.
Raghav Sood
CC BY-SA 4.0
2018-08-09T22:13:58.487Z
@RaghavSood thank you, and thanks to Pieter, JBaczuk, this gives me somewhere to look. If I find out a solution I can amend this thread and add a comment to the open issue on bitcoin core. Thanks!
xagau
CC BY-SA 4.0
2018-09-01T11:44:17.960Z
@PieterWuille, RaghavSood, JBaczuk: I figured out what the issue here was, for reference. I had to do a signrawtransaction in order to make it "work". It seems that something about the client (openwallet-android) signing procedure rejected the signing process in 0.12 bitcoin. After I signed the raw transaction using the latest altcoin client it was able to create a signed transaction "hex" that was accepted by the network.
xagau
<bitcoind><bitcoin-cli><checksig><sighash>
"mandatory-script-verify-flag-failed (signature must be zero for failed check(multi)sig operation)"
xagau
# "mandatory-script-verify-flag-failed (signature must be zero for failed check(multi)sig operation)"

(Asked by: username_0 on 2018-08-09)

I forked the openwallet-android so that I could add my coin - (placeholders) placeh.io.

The openwallet-android connects to electrumx server. I am able to get my chain to load correctly in electrumx server. The openwallet correctly reads the balance from the address / inputs and you can see your balance through the wallet.

However, when I try to broadcast a transaction I am getting the message:

`"mandatory-script-verify-flag-failed (signature must be zero for failed check(multi)sig operation)"`

From placehd/placeh network.

Here is some additional information, this is the rawtransaction that is being published. If I try to send the raw transaction in the placeh-cli client, it will not succeed and produces the same error when done manually

Raw Transaction:

```
placeh-cli decoderawtransaction 

01000000017477f59250a8d8a7d94ba5dcc196222c0b6c92849cad210735b4380b24c03b13010000006a473044022053b17723e8a90846fc341006f5f63d5776df619f33cec82d8065e836508672c6022036298087c2f37c3002c4897b74e7de6af8c608c89cbcef07ada9c5551c85f2810121031dc78b8c254649e204b81641f70497980ca6b5574f837001c962930580d1372dffffffff02c00e1602000000001976a914a117ed0f4e2afe1e1b8d2b0253408a7830f2b55688ac0093e651020000001976a914c472af380586ed1638686731cc1eda3c60363ec788ac00000000
{
  "txid": "de045f2220d0b9f34060336c9ed3badc7c22741fec3aa1d87ff24264c3c1fb5e",
  "hash": "de045f2220d0b9f34060336c9ed3badc7c22741fec3aa1d87ff24264c3c1fb5e",
  "version": 1,
  "size": 225,
  "vsize": 225,
  "locktime": 0,
  "vin": [
    {
      "txid": "133bc0240b38b4350721ad9c84926c0b2c2296c1dca54bd9a7d8a85092f57774",
      "vout": 1,
      "scriptSig": {
        "asm": "3044022053b17723e8a90846fc341006f5f63d5776df619f33cec82d8065e836508672c6022036298087c2f37c3002c4897b74e7de6af8c608c89cbcef07ada9c5551c85f281[ALL] 031dc78b8c254649e204b81641f70497980ca6b5574f837001c962930580d1372d",
        "hex": "473044022053b17723e8a90846fc341006f5f63d5776df619f33cec82d8065e836508672c6022036298087c2f37c3002c4897b74e7de6af8c608c89cbcef07ada9c5551c85f2810121031dc78b8c254649e204b81641f70497980ca6b5574f837001c962930580d1372d"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.35000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 a117ed0f4e2afe1e1b8d2b0253408a7830f2b556 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a117ed0f4e2afe1e1b8d2b0253408a7830f2b55688ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FLWtv6SuocTFMozTZvdZAhroJLehVjLKhs"
        ]
      }
    },
    {
      "value": 99.64000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 c472af380586ed1638686731cc1eda3c60363ec7 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914c472af380586ed1638686731cc1eda3c60363ec788ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FPjqHpEzdYAbxVG2acxz8GWGAPmJsWj6oP"
        ]
      }
    }
  ]
}

```

I believe this may have something to do with the way that the openwallet is constructing the raw transaction. I would like to update the libraries so that it will be able to broadcast the transaction correctly.

**Tags:** bitcoind, bitcoin-cli, checksig, sighash

> **Comments:**
> **username_1**: This means the signature was invalid, perhaps the signature is not being created correctly, maybe the transaction data it is signing doesn't match, or the private key(s) used isn't able to spend the previous output.  
> **username_0**: username_1: Do you have any suggestions about how I might go about fixing this issue? Transactions created and signed in placeh-qt seem to work fine.  
> **username_2**: Without (a) the transaction output being spent and (b) the consensus rules of your altcoin, there is no way to answer this.  
> **username_0**: Thanks username_2, I posted the altcoin source here, it is a "fairly recent" fork of bitcoin core. https://github.com/username_0/placeh  
> **username_3**: Your actual signature is valid (at least according to my bitcoin script vm). Perhaps you're running into something similar to [this](https://github.com/bitcoin/bitcoin/issues/11891). Are you sure openwallet is handling the amounts correctly when signing?  
> **username_1**: @username_3 where are you getting the input scriptPubKey to validate it?  
> **username_0**: username_3, I am not certain. I don't know how long ago openwallet was "actually updated" but it appears to work with Bitcoin, although I have not sent any real bitcoin into it to test. The openwallet fork is over at https://github.com/username_0/openwallet-android. Unfortunately I have to solve this basic plumbing problem before I can try to build on top and its just a bit out of my league. I saw comments about the vout amounts having to add up to an exact amount including the fee but I am a bit unsure.  
> **username_3**: @username_1 Just decoded the address off the explorer linked on the coin site to get the HASH160 (`40840b34365502f6fa5f066b137cf5081b7be8f8`), then just added the opcodes back myself to get `76a91440840b34365502f6fa5f066b137cf5081b7be8f888ac`, which is a standard p2pkh script  
> **username_3**: @username_0 Your amounts under decoderawtransaction seem correct. It's possible that the amounts aren't taken correctly during the signing process, so the amounts in your vout in the raw tx differ from what was signed. This is pure speculation though, based only on the fact that there is an open issue for it in bitcoin core, and that the signature itself is valid.  
> **username_0**: @username_3 thank you, and thanks to username_2, username_1, this gives me somewhere to look. If I find out a solution I can amend this thread and add a comment to the open issue on bitcoin core. Thanks!  
> **username_0**: @username_2, username_3, username_1: I figured out what the issue here was, for reference. I had to do a signrawtransaction in order to make it "work". It seems that something about the client (openwallet-android) signing procedure rejected the signing process in 0.12 bitcoin. After I signed the raw transaction using the latest altcoin client it was able to create a signed transaction "hex" that was accepted by the network.  

---

## 1 answers

### Answer by username_0 on 2018-09-01. Score: 2

After some additional research and helpful information found here, I was able to conclude the following:

Transactions encoded on 0.12.X bitcoin and then broadcast on 0.15 bitcoin may encounter "mandatory-script-verify-flag-failed (signature must be zero for failed check(multi)sig operation)"

This problem can be solved by doing the following:
Signing your 0.12.X raw transaction with a 0.15 signature. I cannot pinpoint the exact issue, however I was able to encode the raw transaction on 0.12.X and the sign it on 0.15 and successfully broadcast it. This information may be useful if someone is trying to figure out what parts of their signing process need to be refactored / updated.


---

