Repository navigation
Conversation
|
Reviews applied and updated the test to make it consistent with the new approach |
thephez
left a comment
There was a problem hiding this comment.
Thanks for the work on this! I've added a few suggestions.
thanks for the review, I have applied your suggestions |
PastaPastaPasta
left a comment
There was a problem hiding this comment.
Sync check against the reference implementation, dashpay/dash#5860 (open, currently conflicting). Nothing in Dash Core v24.0.0 or develop implements this yet.
I recomputed the test vector independently: hashPrevouts, hashSequence, the 402-byte preimage and the final sighash (byte-reversed, as uint256 prints it) all match. SIGHASH_DIP0143 = 0x40 and the preimage field order match #5860.
Mismatches:
- Line 52.
nSequenceis listed as an 8-byte int64_t. It is a 4-byte uint32_t, both inCTxInand in the test vector (ffffffff). There is an inline suggestion. - Deployment (line 178-179). No version bit or parameters are given. #5860 uses
DEPLOYMENT_DIP0143on bit 11, and the DIP should name the bit and window once they are final. - Unstated. #5860 still applies
FindAndDelete(scriptCode, <sig>)to DIP0143 signatures (unlike BIP143 for segwit v0). The DIP should state this explicitly either way, since it is consensus-relevant for scriptCode.
All earlier threads are resolved. What remains is maintainer review, plus getting #5860 rebased and landed so the spec has a shipped counterpart.
🤖 Posted autonomously by Claude on behalf of pasta.
| 5. outpoint (32-byte hash + 4-byte index) | ||
| 6. scriptCode of the input (serialized as pk_script inside CTxOuts) | ||
| 7. value of the output spent by this input (8-byte int64_t) | ||
| 8. nSequence of the input (8-byte int64_t) |
There was a problem hiding this comment.
| 8. nSequence of the input (8-byte int64_t) | |
| 8. nSequence of the input (4-byte uint32_t) |
🤖 Posted autonomously by Claude on behalf of pasta.
Alternative to the old PR #95
This PR describes how the transaction sighash algorithm of BIP143 can be adapted to dash. There are only 2 main differences:
nTypeandvExtraPayloadnVersion = 4and it's deployed with an ehf hard fork.The example in the test section was created with a draft implementation of the algorithm (see dashpay/dash#5860)