archetech / archon / 33351322557

87%

push

github

refactor(cipher): One HD key implementation, on @scure/bip32 (#986)

* test(cipher): Pin HD key derivation to known answers

cipher had one HD assertion -- a JSON round-trip -- and there were no
known-answer tests for derivation anywhere in the repo. Every DID and
wallet is derived through this path, so there was nothing that would fail
if the derived keys changed.

Pinned to fixed strings rather than compared against a second
implementation, so the tests hold whichever library performs the
derivation, and asserted through cipher's public API rather than the
library's, so they stay valid if that library is replaced.

The mnemonic is the canonical BIP-39 test phrase and the master key is
the published value for it. The paths cover BIP-44 for bitcoin and
ethereum, a hardened chain, and the restore-then-derive route a loaded
wallet takes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GYGMfX3foBcVqP7AQNXjWj

* refactor(cipher): One HD key implementation, on @scure/bip32

The repo derived HD keys two ways. cipher-node.ts used `hdkey`, which
requires a native `secp256k1`; cipher-web.ts used @didcid/browser-hdkey,
pure JS on `bells-secp256k1`. Four wallet mediators imported `hdkey`
directly. Nothing tested the two paths against each other.

`secp256k1` publishes no linux-arm64 prebuild in any version, and its
install script is `node-gyp-build || exit 0`, so on arm64 the build fails
silently and secp256k1/index.js substitutes its bundled elliptic
implementation -- 14x slower signing, 32x slower verification, in the 20
images that carry no compiler (#965).

Both existing implementations and @scure/bip32 were checked against each
other first: byte-identical across BIP-32 vectors, derivation paths,
custom version bytes for tpub, and the stored JSON form. @scure/bip32
reads a wallet serialised by `hdkey` and reproduces the same xprv, so no
migration is needed.

@scure/bip32 was chosen over porting browser-... (continued)

3881 of 4464 branches covered (86.94%)

Branch coverage included in aggregate %.

3 of 3 new or added lines in 1 file covered. (100.0%)

8528 of 8953 relevant lines covered (95.25%)

717.57 hits per line