feat: implement the dash analogue to BIP143

[panleone]

Issue being fixed or feature implemented

Implement the bip143 analogue for dash, see here for documenation (dashpay/dips#149).

What was done?

A new sigHashType SIGHASH_DIP0143 has been added and txs inputs with this new sigHashType are signed with the new signature hash algorithm specified in the document.
Feature is activated with an EHF hard fork and controlled with the script flag SCRIPT_ENABLE_DIP0143

How Has This Been Tested?

Many tests have been added:

• Verify that the new signature hash is generated correctly for a set of 100 transactions.
• Verify that script verification will accept new signatures only if there script flag SCRIPT_ENABLE_DIP0143 is set, and the signed input contains the sigHashType SIGHASH_DIP0143
• Verify that both signature (with new and old algorithm) can coexist in the same multisig transaction input and pass script verification, provided that the script flag SCRIPT_ENABLE_DIP0143 is set.
• Verify that the feature is rejected before activation.

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

Would be nice to have 7be17ee in a separate PR. Could maybe also introduce and use another helper like

bool HasExtraPayloadField() const
{
    return IsSpecialTxVersion() && nType != TRANSACTION_NORMAL;
}

while at it.

[UdjinM6]

pls check https://github.com/UdjinM6/dash/commits/pr5860/ branch for wip suggestions, specifically 84905a2

NOTE: I had to revert 0ef6ded and 160dc04 to make it work and also cf150bd to avoid merge conflicts in the future but the latter is optional I guess

[panleone]

pls check https://github.com/UdjinM6/dash/commits/pr5860/ branch for wip suggestions, specifically 84905a2

NOTE: I had to revert 0ef6ded and 160dc04 to make it work and also cf150bd to avoid merge conflicts in the future but the latter is optional I guess

My thoughts:

...
// Drop the signatures when SIGHASH_DIP0143 is not used, since there's no way for a signature to sign itself
    int nHashType = vchSig.empty() ? 0 : vchSig.back();
    if (nHashType & SIGHASH_DIP0143) {
        // Can't use using SIGHASH_DIP0143 hash type without SCRIPT_ENABLE_DIP0143 flag
        if ((flags & SCRIPT_ENABLE_DIP0143) == 0) {
            return set_error(serror, SCRIPT_ERR_SIG_FINDANDDELETE); //TODO
        }
    } else {
        int found = FindAndDelete(scriptCode, CScript() << vchSig);
        if (found > 0 && (flags & SCRIPT_VERIFY_CONST_SCRIPTCODE))
            return set_error(serror, SCRIPT_ERR_SIG_FINDANDDELETE);
    }
...

and

...
// With SCRIPT_VERIFY_CONST_SCRIPTCODE, OP_CODESEPARATOR is rejected even in an unexecuted branch
if (opcode == OP_CODESEPARATOR && /*sigversion == SigVersion::BASE && TODO*/ (flags & SCRIPT_VERIFY_CONST_SCRIPTCODE))
...

DIP0143 would have been a nice moment for imposing no OP_CODESEPARATOR and no signatures inside the script, but we already have a flag for that, SCRIPT_VERIFY_CONST_SCRIPTCODE. I think it is already enough and we don't need to re-impose those conditions with DIP0143, we would just overcomplicate it imo (or there is a particular reason for those additions that I am missing?).

[panleone]

pls check https://github.com/UdjinM6/dash/commits/pr5860/ branch for wip suggestions, specifically 84905a2

NOTE: I had to revert 0ef6ded and 160dc04 to make it work and also cf150bd to avoid merge conflicts in the future but the latter is optional I guess

My idea was that with the current implementation that we have DIP143 can be the very simple: when the right sighash_type is set serialize with the new algorithm , without changing anything else

[UdjinM6]

ok, so then smth like that 1eb9b4e on top I guess?

[panleone]

ok, so then smth like that 1eb9b4e on top I guess?

So that the overall effect is moving this check from CheckSig

if ((nHashType & SIGHASH_DIP0143) && sigversion != SigVersion::DIP0143){
    return false;
}

to EvalScript?

// Can't use using SIGHASH_DIP0143 hash type without SCRIPT_ENABLE_DIP0143 flag
if ((nHashType & SIGHASH_DIP0143) && (~flags & SCRIPT_ENABLE_DIP0143)) {
    return set_error(serror, SCRIPT_ERR_SIG_FINDANDDELETE); //TODO: introduce and use new script error

yes, I like it so we can even get rid of GetSigVersionFromFlags and probably of the whole enum SigVersion

[UdjinM6]

....
yes, I like it so we can even get rid of GetSigVersionFromFlags and probably of the whole enum SigVersion

not sure we can do that but let's see - we need tests :)

[panleone]

....
yes, I like it so we can even get rid of GetSigVersionFromFlags and probably of the whole enum SigVersion

not sure we can do that but let's see - we need tests :)

At the end I tried both methods and the one withSigVersion was much better, so I did not remove it.
So I reverted almost all refactor commits and the only left are:
437ef2f, which however can be removed to have less diff lines;
abad7f4, which removes SigVersion from EvalScript (because that variable was unused)

[UdjinM6]

Looks good so far! Pls see b100c66, d69d345 and 429db53 for some suggestions/fixes.

[panleone]

Looks good so far! Pls see b100c66, d69d345 and 429db53 for some suggestions/fixes.

review applied, with the addition of 00d60b9

[github-actions]

This pull request has conflicts, please rebase.

[DashCoreAutoGuix]

❌ Backport Verification - Issues Detected

Original Bitcoin commit: N/A (Dash-native DIP0143 implementation)
Reviewed commit hash: 0a2b5c8-verify-1753723784

Issues found:

• Extensive reviewer feedback requiring manual resolution: Multiple detailed technical discussions between maintainers (@UdjinM6, @panleone) about implementation approaches, architectural decisions, and code structure changes
• Merge conflicts need manual rebasing: GitHub Actions reports conflicts that require manual resolution
• No CI validation: No automated testing has been run on this PR to validate the implementation
• Complex feature implementation: This implements a new signature hashing algorithm (DIP0143) that requires expert security review and cannot be automatically validated

Note: This is not a Bitcoin backport but a Dash-native feature implementation. The standard backport verification process does not fully apply, but the PR requires significant manual work to address reviewer feedback and conflicts before it can be considered ready for merge.

Please address the reviewer feedback from @UdjinM6 and @panleone, resolve merge conflicts, and ensure CI passes before re-requesting verification.

[thepastaclaw]

Review Gate

Commit: 0a2b5c87

• ✅ Debounce: 1167598m ago (need 30m)

• ✅ CI checks: no CI checks found

• ⏳ CodeRabbit review: no comment yet

• ✅ Off-peak hours: off-peak (03:33 AM PT Tuesday)

• Run review now (check to override)

[thepastaclaw]

Code Review

One real consensus issue: DIP0143 verification still applies legacy FindAndDelete to scriptCode, diverging from the verbatim hashing in SignatureHash and breaking BIP143-style semantics for spends whose script contains signature bytes. A functional-test helper also serializes vExtraPayload without its CompactSize prefix, diverging from C++ and any unit-test reference. The regtest-only deployment is explicit in the commit history (feat: add DIP0143 regtest params), so that is a staged-rollout observation rather than a blocker.

Reviewed commit: 0a2b5c8

🔴 1 blocking | 🟡 1 suggestion(s) | 💬 1 nitpick(s)

blocking: DIP0143 verification still applies FindAndDelete to scriptCode

src/script/interpreter.cpp (lines 356-359)

SignatureHash(..., SigVersion::DIP0143) at lines 1561-1609 hashes the supplied scriptCode verbatim (the central point of the BIP143-style preimage). However, EvalChecksig() at line 357 unconditionally calls FindAndDelete(scriptCode, CScript() << vchSig) before invoking checker.CheckSig, and the OP_CHECKMULTISIG path repeats the same unconditional deletion at lines 1178-1181. After DIP0143 activation, any spend whose executed script tail contains a signature byte sequence will be verified against a different preimage than the signer produced, causing valid DIP0143 signatures to fail (or, worse, divergent consensus across implementations that get this right vs. wrong). BIP143 specifically forbids FindAndDelete on the scriptCode for this reason; DIP0143 must do the same. The current unit tests only sign simple scripts where the signature bytes never appear in scriptCode, so they cannot catch this. Gate the FindAndDelete call behind sigversion == SigVersion::BASE (or skip when nHashType & SIGHASH_DIP0143 is set and the flag is enabled), matching BIP143's behavior in segwit code paths.

suggestion: DIP0143SignatureHash serializes vExtraPayload without CompactSize length prefix

test/functional/test_framework/script.py (lines 710-711)

The C++ preimage hashes extra payload with ss << txTo.vExtraPayload (interpreter.cpp:1601-1602), which—because vExtraPayload is a std::vector<unsigned char>—includes a CompactSize length prefix. Dash's Python serializer matches this: CTransaction.serialize_with_witness calls ser_string(self.vExtraPayload) (messages.py:495). The new DIP0143SignatureHash helper instead appends the raw bytes (ss += txTo.vExtraPayload), so any future functional test signing a version-3 special transaction with DIP0143 will compute the wrong hash. Use ser_string to match the on-the-wire encoding.

    if (txTo.nVersion == 3 and txTo.nType != 0):
        ss += ser_string(txTo.vExtraPayload)

nitpick: DIP0143 deployment parameters are only set on regtest

src/chainparams.cpp (lines 836-843)

DEPLOYMENT_DIP0143 parameters are added solely inside CRegTestParams (chainparams.cpp:836-843). Mainnet, testnet, and devnet constructors leave the deployment zero-initialized, so SCRIPT_ENABLE_DIP0143 will never be set in GetBlockScriptFlags() on persistent networks. The commit history (1c313a9c3a feat: add DIP0143 regtest params) suggests this is an intentional staged rollout where mainnet/testnet/devnet activation lands in a follow-up. Worth confirming with the PR author that this is deliberate, and tracking the follow-up to add the production deployments before DIP0143 is announced as usable.

_Inline posting via scripts/review_poster.py failed, so I posted the verified findings in the review body instead: Traceback (most recent call last):
File "/Users/claw/.openclaw/workspace/scripts/review_poster.py", line 138, in
result = post_review(repo, pr_number, head_sha, verified, dry_run=dry_run)
File "/Users/claw/.openclaw/workspace/scripts/review_poster.py", line 107, in post_review
result = _gh(
File "/Users/claw/.openclaw/workspace/scripts/review_poster.py", line 23, in gh
raise RuntimeError(f"gh {' '.join(args)} failed: {result.stderr.strip()}")
RuntimeError: gh api /repos/dashpay/dash/pulls/5860/reviews --method POST --input - failed: gh: Unprocessable Entity (HTTP 422)