Decoupled Watch – Creating a raw Segwit transaction from scratch and getting its signature must be 0 for a failed CHECK(MULTI)SIG operation.
I’m trying to create a Segwit transaction in TESTNET from scratch, referring to the online guide: https://medium.com/coinmonks/creating-and-signing-a-segwit-transaction-from-scratch-ec98577b526a
My BIP-39 mnemonic code:
differ toast alert candy orbit raccoon wagon hour thunder kiwi home cigar
My TESTNET BIP-32 master public key derived the Segwit Bech32 address using the derivation path ‘m’.
tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj
The address profile can be viewed here.
To simplify debugging, only the derivation ‘m’ is used.
For more information, see Master Public Key Compression Format.
03D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385A
For more information, see Master Public Key Uncompressed Format.
04D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385AE1DEED79187355D35FDABAF74DFD186A8B8C9FE1D6357AA46750A47B86ED16CF
Raw BIP-32 seed:
1CD4561EF82D35F9EE2E95ED63B68BB91ADA8967E1D98FA4080637A4CC310BE99DD285F82F45EE004ADC408F8B93C2A829A5B811104496A6FB0301E062CBC813
Raw master private key later used for digital signature:
13D84CAC526896CEF2594D71621D2AEDC90F9DAEA88A1751AD99E35868E0021B
Some funds (0x550300000000000000000000/85) to myself (tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj) using my address (tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj) I would like to send 3 satoshis).
So I start generating Segwit inputs that will be signed after a double SHA256 hash.
Follow the BIP143 definition steps.
Double SHA256 of the serialization of:
1. nVersion of the transaction (4-byte little endian)
2. hashPrevouts (32-byte hash)
3. hashSequence (32-byte hash)
4. outpoint (32-byte hash + 4-byte little endian)
5. scriptCode of the input (serialized as scripts inside CTxOuts)
6. value of the output spent by this input (8-byte little endian)
7. nSequence of the input (4-byte little endian)
8. hashOutputs (32-byte hash)
9. nLocktime of the transaction (4-byte little endian)
10. sighash type of the signature (4-byte little endian)
// 1. nVersion of the transaction (4-byte little endian)
<<< 01000000
// 2. hashPrevouts (32-byte hash)
>>> printf "4E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0 00000000" | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b
<<< 04dc164c0a705f5d2d57fd42e6896a94394e6966ed0b116a64adfaa9310b848f
// 3. hashSequence (32-byte hash)
>>> printf "ffffffff" | xxd -p -r | sha256sum | xxd -p -r | sha256sum
<<< 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
// 4. outpoint (32-byte hash + 4-byte little endian)
<<< 4E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0 00000000
// 5. scriptCode of the input (serialized as scripts inside CTxOuts)
<<< 1976a914149185A045594EDDD9C1A895A75D1A5FEAE2C34388ac
// 6. value of the output spent by this input (8-byte little endian)
<<< e803000000000000
// 7. nSequence of the input (4-byte little endian)
<<< ffffffff
// 8. hashOutputs (32-byte hash)
>>> printf "e803000000000000 16 0014149185A045594EDDD9C1A895A75D1A5FEAE2C343" | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b
<<< 7c007a193409e64199438db0ba4349809fbcc42c17e7167cbc06deec4cc0998f
// 9. nLocktime of the transaction (4-byte little endian)
<<< 00000000
// 10. sighash type of the signature (4-byte little endian)
<<< 01000000
// Hashing with double Sha256
>>> printf 0100000004dc164c0a705f5d2d57fd42e6896a94394e6966ed0b116a64adfaa9310b848f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650444E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0000000001976a914149185A045594EDDD9C1A895A75D1A5FEAE2C34388ace803000000000000ffffffff7c007a193409e64199438db0ba4349809fbcc42c17e7167cbc06deec4cc0998f0000000001000000 | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b
<<< c2636fae9487354f47e4e92458a7e856f717533c6d01e1c5fda5b06c4a1976a8
Encoded digital signature result:
30450221008B61503427B2292F781405712DF878B207D8B89FC86D60B1A68D479CA6C6FF2302203BB1F7F5F7E2B9050BA481310C997F6F078F5ED25564AEC85277EB56BA98FD76
Finally, it is formatted as a raw transaction below.
010000000001014E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A00000000000FFFFFFFF015503000000000000160014149185A045594EDDD9C1A895A75D1A5FEAE2C343024830450221008B61503427B2292F781405712DF878B207D8B89FC86D60B1A68D479CA6C6FF2302203BB1F7F5F7E2B9050BA481310C997F6F078F5ED25564AEC85277EB56BA98FD76012103D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385A00000000
The following error occurs in the broadcast results:
sendrawtransaction RPC error: "code":-26,"message":"non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)"
Assuming all the above addresses and scripts are valid, I have checked the digital signature several times and run validation checks on the signature and public key.
How do I fix a failed broadcast? What is the cause of broadcast failure?