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, ...
3
Using this library:
from cryptotools import Signature, PublicKey, hex_to_bytes
pub = PublicKey.from_hex('025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357')
sig = Signature.from_hex('304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee')
sighash = ...
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
2
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
2
ok So thanks to PieterWuille I (we) were able to figure out why my code wasn't working and how to use a standard python or openssl library.
These were the following problems
the DER decoding for the python library was used incorrectly. We needed to iterate through all the variables and pull the two pieces of the signature (r and s) our separately and ...
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
this formatting doesn't appear to be defined anywhere in this document?
The formatting follows the standard Bitcoin script. The main difference between the witness stack and traditional Bitcoin script is that instead of pushing things to the stack via a script, the stack is just provided. So all of the encodings are just as if it were a Bitcoin script.
...
1
When you are creating signatures, you are signing for a specific input in the transaction. That specific input has a corresponding outpoint, so you use its outpoint in the sighash.
In the examples given, the sighashes for all of the inputs are given. So for each input, it makes a sighash using the outpoint for that input.
In this example, if you are signing ...
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
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