Proposing a feature?
rust_jsi_bridge/src/lib.rs is the cryptographic core of the wallet — it does all BIP-352 scanning (ECDH, tagged hashing, output-key derivation) and is consumed from TypeScript over the C FFI. It currently has zero tests, and no CI workflow runs cargo test.
This is the highest-consequence untested code in the repo. A silent regression in the scanner means either missed payments (funds look lost) or a matched UTXO whose returned tweakHex cannot actually derive a spending key.
What I'd like to add
An inline #[cfg(test)] mod tests in lib.rs covering:
compute_shared_secret_hash — the BIP0352/SharedSecret tagged hash and its
big-endian output-index encoding
ecdh_shared_secret — sender/receiver ECDH duality
derive_expected_pubkey — P_k = B_spend + t_k*G
parse_scan_tweak — all error paths
build_output_map, scan_outputs, scan_transaction
process_transactions_parallel — counters and rayon output ordering
- The serde wire contract with
modules/RustJsiBridge.ts (camelCase keys)
- The FFI boundary — null pointers, error wrapping, the embedded-NUL fallback
Plus a small workflow so the tests actually gate PRs.
On not writing circular tests
The obvious approach — build a fixture with derive_expected_pubkey, then assert scan_transaction finds it — is worthless: it passes even if the crypto is completely wrong. So every expected value would be computed from the sender's side of BIP-352 using different secp256k1 APIs than the scanner uses (mul_tweak/combine against shared_secret_point/add_exp_tweak), and the tagged hash rebuilt by hand from raw sha256, bypassing the sha256t_hash_newtype! macro.
Notes
- No new dependencies — everything is doable with the existing
secp256k1, bitcoin_hashes, hex, and serde_json.
- No production changes.
Cargo.toml already has crate-type = [..., "lib"] ("Rust library for tests and examples"), so cargo test works as-is.
- Tests go inline rather than in
tests/ because nearly every function under test is private.
Proposing a feature?
rust_jsi_bridge/src/lib.rsis the cryptographic core of the wallet — it does all BIP-352 scanning (ECDH, tagged hashing, output-key derivation) and is consumed from TypeScript over the C FFI. It currently has zero tests, and no CI workflow runscargo test.This is the highest-consequence untested code in the repo. A silent regression in the scanner means either missed payments (funds look lost) or a matched UTXO whose returned
tweakHexcannot actually derive a spending key.What I'd like to add
An inline
#[cfg(test)] mod testsinlib.rscovering:compute_shared_secret_hash— theBIP0352/SharedSecrettagged hash and itsbig-endian output-index encoding
ecdh_shared_secret— sender/receiver ECDH dualityderive_expected_pubkey—P_k = B_spend + t_k*Gparse_scan_tweak— all error pathsbuild_output_map,scan_outputs,scan_transactionprocess_transactions_parallel— counters and rayon output orderingmodules/RustJsiBridge.ts(camelCase keys)Plus a small workflow so the tests actually gate PRs.
On not writing circular tests
The obvious approach — build a fixture with
derive_expected_pubkey, then assertscan_transactionfinds it — is worthless: it passes even if the crypto is completely wrong. So every expected value would be computed from the sender's side of BIP-352 using different secp256k1 APIs than the scanner uses (mul_tweak/combineagainstshared_secret_point/add_exp_tweak), and the tagged hash rebuilt by hand from raw sha256, bypassing thesha256t_hash_newtype!macro.Notes
secp256k1,bitcoin_hashes,hex, andserde_json.Cargo.tomlalready hascrate-type = [..., "lib"]("Rust library for tests and examples"), socargo testworks as-is.tests/because nearly every function under test is private.