AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 34 Bitcoin

Simplify internal key validation for taproot (#820)

Public commit record

What the developer wrote

Authored by Pac

96/100 · Strong
Simplify internal key validation for taproot (#820)

* Simplify internal key validation for taproot

There is no standard for how to generate the taproot keypath chaincode to be used with the NUMS pubkey.
Liana does it by hashing the taptree keys;
Coldcard uses a random chaincode;
Nunchuck hashes the taptree keys, but remove duplicates and sort the keys before hashing.
This fix changes the verification logic to check only the NUMS pubkey and ignore the chaincode.

* Allow loading of non-deterministic chain code in wallet

The wallet now loads the non-deterministic chain code without raising an error, indicating it is considered valid.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This change relaxes how Krux checks the 'internal key' used in Taproot multisig wallets. Previously it required the wallet to use a specific deterministic chain code derived from the other public keys; now it only checks that the internal key is the well-known NUMS (provably unspendable) public key and ignores the chain code. This makes Krux compatible with wallets like Coldcard and Nunchuck that use different chain-code conventions, but it removes a validation step that ensured the internal key was constructed in a specific reproducible way.

Recommended action

Review whether ignoring the chain code is acceptable for all supported wallet policies. The NUMS pubkey check still prevents key-path spending, but users should confirm that descriptor parsing and taptree validation otherwise reject malicious descriptors. Consider documenting the rationale and any residual risks for cross-vendor compatibility.

Security signals we found

01

Validation scope reduced: chain-code derivation check removed

02

Taproot internal-key trust boundary relaxed

03

NUMS pubkey check retained, so funds remain provably unspendable via key path

04

No cryptographic bug fixed; change is interoperability-driven

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.