This implements support for different fork id values as per https://github.com/bitcoincashorg/spec/blob/master/replay-protected-sighash.md .
Depends on D1189
Details
Details
- Reviewers
jasonbcox - Group Reviewers
Restricted Project - Maniphest Tasks
- T301: Automatic Future Hardfork Replay Protection
- Commits
- rSTAGINGd9ae52833d7d: Add support for having different forkid values in SigHashType
rABCd9ae52833d7d: Add support for having different forkid values in SigHashType
Updated untitests to check the new feature.
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| src/script/sighashtype.h | ||
|---|---|---|
| 51 ↗ | (On Diff #3161) | Do we need to communicate out to the other clients that the second byte of sighash will contain the forkid version? If there's a spec, please link it in the summary. I found these meeting notes that mention the change, but no implementation details: https://github.com/bitcoincashorg/workgroups/blob/master/wg-hardforks/summaries/20180202%20-%20Meeting%20Summary.md |
| src/test/script_sighashtype_tests.cpp | ||
| 33 ↗ | (On Diff #3161) | Does the range of supported forkIds need to be so large? |
| 38 ↗ | (On Diff #3161) | Any reason to not simply iterate all possible values of forkId? |
| src/script/sighashtype.h | ||
|---|---|---|
| 51 ↗ | (On Diff #3161) | They should already know if they read https://github.com/bitcoincashorg/spec/blob/master/replay-protected-sighash.md And if they did not, then tough luck, I guess. |
| src/test/script_sighashtype_tests.cpp | ||
| 33 ↗ | (On Diff #3161) | It is a common address space between all the shitfork of bitcoin, so yes, it needs to be. |
| 38 ↗ | (On Diff #3161) | Because the range is very large, as you noted. |