4
Bitcoin Cash uses BIP 143 for signature hash creation.
From the BIP:
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 ...
3
I'm just guessing, but by having the transaction commit to the scriptCode, we ensure that the signer knows what script they're signing for. A hardware wallet, for example, can only be certain that outpoint 1234...cdef:0 pays a particular script if we give it the transaction that created that outpoint (so that it can hash that transaction, verify the txid, ...
2
From BIP143:
If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256
of the serialization of all input outpoints;
Otherwise, hashPrevouts is a uint256 of 0x0000......0000.
All the details you need are in the BIP
1
The way I understand it, the important part is that for BIP-143 each signature is only calculated for the amount that it's own input spends. For the other inputs only their outpoints (txid+txidx) are used for the signature digest.
Let's assume you have two UTXOs, one with 15 BTC at outpoint txid0:txidx0 and another with 20 BTC at outpoint txid1:txidx1.
...
1
I believe you can use either at this stage. The marker and the flag show let the client decipher which scheme is being used and interpret appropriately.
lockTime sets when the transaction is valid from. 0x00 is from the first block, 0x11 is from a later block. You can continue to use 0x00 if you wish. https://bitcoin.org/en/glossary/locktime. Most ...
1
I found the problem, in the bip143 tx digest preimage, the scriptCode needs to be preceded by the length of the scriptCode. In this case 0x47
1
Only the private key for the second input is used in this signature as this signature is only for the second input. The first input is P2PK and is ignored in this example as it is non-segwit so the standard non-segwit sighash algorithm is used for it.
1
After a while of debugging, I was able to find the issue.
My previous assumption that I was committing the wrong data to the hash was correct.
The transaction ID that is needed to construct hashPrevouts and outpoint was incorrect. I needed to reverse the bytes of this value for the hash to be correct.
For example:
...
Only top voted, non community-wiki answers of a minimum length are eligible
