[SOLVED] Error: Script was NOT verified successfully.

[NotATether]

This is an error I got from blockcypher when trying to broadcast my programmatically created P2WPKH transaction.

Apparently, the script validation in input 0 failed but I'm not sure how.

Can anyone help me figure this out? The error and Decoded transaction is below.

Error validating transaction: Error running script for input 0 referencing c53efc1e8592cbe103c732a1dae6f94c339a529190ee1ee9ee3699fa9f711c96 at 0: Script was NOT verified successfully..

Code:

{
    "addresses": [
        "tb1qsrmc2j2u3uc2zdqzegehkg0k6hr9lv8klfp08x",
        "tb1q7xzhqrxxnzehxtww9y24pff58h0jg876c0jy38",
        "tb1qcg3f6ehwlaseqz6x0zers5lq4pgzmat2tl6znq"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 140,
    "hash": "93176f012b10c8889023329f3f1de24755461764f55876f0f5cef3e2914e5c54",
    "inputs": [
        {
            "addresses": [
                "tb1q7xzhqrxxnzehxtww9y24pff58h0jg876c0jy38"
            ],
            "age": 2574289,
            "output_index": 0,
            "output_value": 100651112,
            "prev_hash": "c53efc1e8592cbe103c732a1dae6f94c339a529190ee1ee9ee3699fa9f711c96",
            "script_type": "pay-to-witness-pubkey-hash",
            "sequence": 2147483648,
            "witness": [
                "30450221009ce0f2e09109b7890329813d62feac316183287c1da9e06c4119d8c49fb5388f02201ed7a92550c11a8ab4c7025c0f4371fd1039d7f46b0842fa78f424df3f2d7fd401",
                "038b0254d8b428b0516b9337ce48f7549eb429637c8fa445ee7594eda21c511762"
            ]
        }
    ],
    "opt_in_rbf": true,
    "outputs": [
        {
            "addresses": [
                "tb1qcg3f6ehwlaseqz6x0zers5lq4pgzmat2tl6znq"
            ],
            "script": "0014c2229d66eeff61900b4678b23853e0a8502df56a",
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 10000
        },
        {
            "addresses": [
                "tb1qsrmc2j2u3uc2zdqzegehkg0k6hr9lv8klfp08x"
            ],
            "script": "001480f785495c8f30a13402ca337b21f6d5c65fb0f6",
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 100640972
        }
    ],
    "preference": "low",
    "received": "2024-01-19T17:17:49.370626937Z",
    "relayed_by": "54.90.95.17",
    "size": 223,
    "total": 100650972,
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 2,
    "vsize": 141
}

Transaction hex:

Code:

01000000000101961c719ffa9936eee91eee9091529a334cf9e6daa132c703e1cb92851efc3ec5000000000000000080021027000000000000160014c2229d66eeff61900b4678b23853e0a8502df56acca8ff050000000016001480f785495c8f30a13402ca337b21f6d5c65fb0f6024830450221009ce0f2e09109b7890329813d62feac316183287c1da9e06c4119d8c49fb5388f02201ed7a92550c11a8ab4c7025c0f4371fd1039d7f46b0842fa78f424df3f2d7fd40121038b0254d8b428b0516b9337ce48f7549eb429637c8fa445ee7594eda21c51176200000000

[1714531827]

1714531827

[1714531827]

1714531827

[1714531827]

1714531827

[1714531827]

1714531827

[NotATether]

I see they haven't spent it yet.
Here are some things to check:

Code:

prevHash: c53efc1e8592cbe103c732a1dae6f94c339a529190ee1ee9ee3699fa9f711c96
prevId:   0
prevValue:1.00651112
prevPk:   0014f185700cc698b3732dce291550a5343ddf241fda
SigHash:  908eb3dc1eeb3bbe81a8c9a021ef1d5c18099c89bd05a2820c645bd6341001d1
SigR:     009ce0f2e09109b7890329813d62feac316183287c1da9e06c4119d8c49fb5388f
SigS:     1ed7a92550c11a8ab4c7025c0f4371fd1039d7f46b0842fa78f424df3f2d7fd4
PubKey:   038b0254d8b428b0516b9337ce48f7549eb429637c8fa445ee7594eda21c511762

The signature is NOT correct!
Check the SigHash first!

before SigHash:

Code:

SigHash = SHA256²(01000000e32ee50d3590001a0ecaf1230d7da066bccf1fedd4d3522bcc04468dbd505fb08f64b0c3a7d964081e85a1401845112be7ea0c37947b7e57a9dc74a20ff19dc2961c719ffa9936eee91eee9091529a334cf9e6daa132c703e1cb92851efc3ec5000000001976a914f185700cc698b3732dce291550a5343ddf241fda88ac68d0ff0500000000000000802d8ec028e17bdc13acf29fd0776da8d5eea92844f6885d6c91ade88005fc60c80000000001000000)

That's not good.

I realized that I was not double hashing the outpoints list before putting them in the sighash, but I still get an error.

Sighash for a new transaction (before signing):

0100000046111bba17bad101669337a4c13f11953520347f16e5757949e9bebf52d01a068f64b0c 3a7d964081e85a1401845112be7ea0c37947b7e57a9dc74a20ff19dc294dabca706fe011969ea96 490924a40e961d7573af034d28513718d6b9dccc2f0000000076a91480f785495c8f30a13402ca3 37b21f6d5c65fb0f688acfacfff05000000000000008055c6c38707420170e30c334bcc539feec4 e469bdab6711dddff92ef11e97ba3c0000000001000000

Version is 1, hashPrevouts (before double hashing) is 94dabca706fe011969ea96490924a40e961d7573af034d28513718d6b9dccc2f00000000 [i.e. the input is txid 94dabca..., #0]

hashSequence is 00000080 (note: It is not 0xffffffff because I want to use RBF, but it should mean that timelocks are not enabled)

hashOutputs is 021027000000000000160014c2229d66eeff61900b4678b23853e0a8502df56a000000000000000 0160014c2229d66eeff61900b4678b23853e0a8502df56a (the single output of this transaction along with script pubkey)

The script added (directly without hashing is 76a91480f785495c8f30a13402ca337b21f6d5c65fb0f688ac - P2PKH script, since I was told that P2WPKH UTXOs requie this

Locktime is 00000000 and sighash type is SIGHASH_ALL ie 01000000.

I use the coincurve package for signing transactions so there should be no issues with the DER signing itself.

Sorry for the really long output, I'm really confused here to be honest

Also the scriptsig before I sign the transaction is set to 0x00, I think I left it like that in the final tx.

EDIT: Can confirm that the public key in the witness is coreect and that the signature is NOT correct, for some reason.

[pooya87]

The sighash you produced for signing is wrong and here is some of the bugs in your computation:

Version is 1, hashPrevouts (before double hashing) is 94dabca706fe011969ea96490924a40e961d7573af034d28513718d6b9dccc2f00000000 [i.e. the input is txid 94dabca..., #0]

The tx hash of the input of the transaction you posted in OP is 96c171...3ec5 so the hash you used here is wrong.

hashOutputs is 021027000000000000160014c2229d66eeff61900b4678b23853e0a8502df56a0000000000000000160014c2229d66eeff61900b4678b23853e0a8502df56a (the single output of this transaction along with script pubkey)

There is no 02 at the beginning of the bytes you hash for hashoutputs. It is concatenation of outputs without count. (total size should be 66 bytes for your transaction here).
Your second output is also being written to the stream wrong, you set the amount to zero instead of cca8ff0500000000 which is 100640972 satoshi.
Your second output script is also wrong, you used the first output script again (0xc222... instead of 0x80f7...)

[NotATether]

The sighash you produced for signing is wrong and here is some of the bugs in your computation:

Version is 1, hashPrevouts (before double hashing) is 94dabca706fe011969ea96490924a40e961d7573af034d28513718d6b9dccc2f00000000 [i.e. the input is txid 94dabca..., #0]

The tx hash of the input of the transaction you posted in OP is 96c171...3ec5 so the hash you used here is wrong.

hashOutputs is 021027000000000000160014c2229d66eeff61900b4678b23853e0a8502df56a0000000000000000160014c2229d66eeff61900b4678b23853e0a8502df56a (the single output of this transaction along with script pubkey)

There is no 02 at the beginning of the bytes you hash for hashoutputs. It is concatenation of outputs without count. (total size should be 66 bytes for your transaction here).
Your second output is also being written to the stream wrong, you set the amount to zero instead of cca8ff0500000000 which is 100640972 satoshi.
Your second output script is also wrong, you used the first output script again (0xc222... instead of 0x80f7...)

Since I also happen to be debugging legacy tx signing, I implemented your suggestions except for the prevouts section since it really was a different UTXO, and what I found was the sighash is actually supposed to be hashed once, not twice.

It was a very hard to spot error, if you ask me.

Anyway, once I did that, I was able to broadcast my legacy transactions alright. I haven't tested the new changes with my Segwit implementation yet, but I wouldn't be surprised if there are a few more bugs hiding in there.


Edit: So segwit still does not work, and preimages are actually double-hashed according to BIP143, and the scriptCode for P2WPKH is supposed to be a P2PKH script, however, my DER signature is still 48 bytes long (bad sign) instead of 47 bytes as I noticed on most valid transactions (r value 256 bits, s-value 250 bits).


EDIT 2:

This is getting annoying!

So it looks like my Segwit signatures are now valid, according to this: https://siminchen.github.io/bitcoinIDE/build/editor.html Nevermind, I spoke too soon.

Code:

304402204debeb5016c334d75026c479fe101da11b23b8044fc5734d7bb9c6cbb392fecc02201119ee947c1ea67b3bfe15006409d1ec8c595ae95a258319cfb3429b0cb4223a01
OP_CHECKSIG

The signature is even 71 bytes.

Yet I still get that same error -26 that's for failed scripts.

Is there some other part of my signed tx that is wrong?

[pooya87]

Have you tried reproducing the signature from the BIP? https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#native-p2wpkh

It has all the intermediate hashes for hashPrevouts, hashSequence, etc. all the way to the serialized signed transaction so you can verify your every step when producing the sighash and find the bug easier that way. Just hard code the values into your code and have it break if it is wrong.
For example

Code:

expectedHashPrevoutStream = "fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000"
expectedHashPrevout = "96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37"

// write to your stream
Assert(myHashPrevoutStream == expectedHashPrevoutStream)
// compute hash
Assert(myHashPrevout  == expectedHashPrevout)

[NotATether]

Solved, finally!

The outpoint txid was written in the wrong way (twice). The outpoint should be written as [reversed TXID] [AMOUNT] where [reversed TXID] is in little endian, that means the transaction bytes (NOT hex characters!) have to be reversed! you cannot just write the TXID the way it is (big-endian across the Bitcoin network).