PQ Test Vectors

Tidecoin’s post-quantum behavior is tested with a mix of JSON fixtures, unit tests, and functional tests. Vectors are part of the compatibility contract for other implementations.

This page is for contributors and library authors. It is not the normative signature specification; see Protocol / Signatures.

Vector Locations

File or test	Covers
`src/test/data/script_tests_pq.json`	PQ script interpreter cases
`src/test/data/tx_valid_pq.json`	Valid PQ transaction cases
`src/test/data/tx_invalid_pq.json`	Invalid PQ transaction cases
`src/test/pqhd_kdf_tests.cpp`	PQHD derivation behavior
`src/test/pqhd_keygen_tests.cpp`	PQHD deterministic key generation
`src/test/pq_multisig_tests.cpp`	PQ multisig behavior
`src/test/pq_txsize_tests.cpp`	PQ transaction sizing assumptions
`src/test/auxpow_tests.cpp`	AuxPoW validation behavior
`test/functional/feature_pq_script_assets.py`	Script behavior through node RPC/regtest

Adding a Vector

Identify whether the behavior is consensus, policy, wallet, or integration.
Prefer an existing vector format if one already covers the behavior.
Include both valid and invalid cases when practical.
Add a unit test or functional test that fails without the new vector.
Keep vector data deterministic.
Document the scheme, path, script flag, or activation rule involved.

Cross-Implementation Use

External libraries should use vectors to verify:

scheme-prefixed public key parsing;
signature encoding and sighash handling;
PQHD path and seed derivation;
script flag activation behavior;
witness v1 SHA-512 script-hash behavior;
AuxPoW serialization and validation.

Do not copy wallet secrets from examples into production wallets.

Review Checklist

Does the vector cover the activated and non-activated rule if activation matters?
Does it test malformed data, not only happy paths?
Does it avoid relying on ECDSA or Bitcoin-only descriptor behavior?
Does it include the right scheme prefix?
Does it have a source test that runs in CI or local test commands?