Deep Technical Audit

Transaction Malleability + Signature Encoding

This audit separates transaction-level malleability, DER/signature encoding rules, public-key encoding, script execution and the limits of what can be claimed from the currently reviewed VTA source evidence. A transaction can be consensus-valid while still admitting multiple serialized forms if the signed commitment does not cover the changed bytes.

Signature Encoding

AUDIT AREA

Check whether signature encoding is constrained to canonical forms before script verification accepts the signature.

Public-Key Encoding

AUDIT AREA

Separate signature encoding from public-key encoding. They are different validation surfaces.

Modern Malleability Rules

NOT ASSUMED

SegWit witness commitments and modern BIP-specific rules are not imported into VTA evidence.

Malleability Flow

VTA Audit Matrix

Area	Documented finding	Status
Strict signature encoding	The previously verified VTA transaction-validation path invokes `CheckInputs()` with `SCRIPT_VERIFY_P2SH \| SCRIPT_VERIFY_STRICTENC`.	Source path verified
ECDSA script operations	The reviewed VTA script engine contains CHECKSIG and CHECKMULTISIG execution paths.	Source path verified
Signature hash	Signature validation is connected to a transaction-derived signature digest and SIGHASH type in the legacy architecture.	Architecture documented
Canonical signature encoding	STRICTENC is an explicit validation flag in the reviewed transaction-input verification path.	Source path verified
Low-S normalization	No independent VTA-specific low-S consensus test was executed by this audit.	Not measured
Public-key canonicality	Public-key encoding rules require release-specific test vectors to establish exact VTA consensus behavior.	Needs test vectors
Transaction-ID malleability corpus	No before/after serialized transaction pair was executed against VTA Core in this package.	Not measured
SegWit witness malleability	Modern witness-based anti-malleability rules are not treated as VTA evidence.	Not established

What to Test Next

1. Take one known-valid VTA transaction.
2. Produce controlled signature-encoding variants.
3. Recalculate the serialized transaction ID.
4. Submit each variant to a VTA Core test node.
5. Record accepted/rejected result and exact error.
6. Repeat for CHECKSIG and CHECKMULTISIG.
7. Test public-key encoding variants separately.
8. Compare behavior against the exact VTA release/commit.

Important Distinction

Canonical signature encoding ≠ “all malleability solved.” Strict encoding can remove specific alternate encodings, but transaction malleability is broader. The signed fields, SIGHASH mode, script behavior, transaction serialization, and any witness/modern protocol features all matter. This page therefore does not assign a blanket “malleability solved” conclusion.