fix(signer): validate wildcard derivation paths

[busayo-OD]

Fixes #563

Description

SignerWrapper<DescriptorXKey<Xpriv>>::sign_input uses DescriptorXKey::matches() to determine whether a PSBT key origin
matches the signer. Since matches() ignores the final derivation step for wildcard descriptors, a hardened child could be accepted for an unhardened wildcard, and vice versa.

Notes to the reviewers

DescriptorXKey::matches() intentionally ignores the wildcard's final path step, so the additional check is required to validate the wildcard-specific derivation constraint.

Added regression tests covering both hardened and unhardened wildcard descriptors and their valid and invalid derivation paths, through both the bip32_derivation and tap_key_origins key-origin paths.

Changelog notice

• Validate wildcard derivation hardness when signing with an xprv signer

Before submitting

• I followed the contribution guidelines
• This PR breaks the existing API

[j-kon]

ACK 6b15185

Reviewed and verified:

• Confirmed reproduction of #563 on master: 0/* signed for m/0/1h and 0/*h signed for m/0/1.
• Confirmed PR #569 rejects both invalid combinations and accepts legitimate ones across both debug and release builds.
• Verified that DescriptorXKey::matches() guarantees prefix equality and length (compare_path.len() + 1), so keysource.1.into_iter().last() is guaranteed to be the wildcard child step.
• Verified path length edge cases (missing child, extra steps, empty paths) and Wildcard::None exact path matching.
• Verified that tap_key_origins (Taproot key-path and script-path) enforces the same wildcard hardness checks.
• Verified that multiple candidate origins in find_map skip invalid entries without error and sign valid ones.

[Jennycj]

Thanks for this fix. I was able to run the tests without the fix and reproduced the bug, which this commit fixes.

I have an observation though: I think that tests should be added to cover the tap_key_origins path as the tests currently cover the bip32_derivation path. Even though the check covers both, any change that is made to taproot that makes taproot entries skip the check would slip through because they are not being asserted here.

[busayo-OD]

I have an observation though: I think that tests should be added to cover the tap_key_origins path as the tests currently cover the bip32_derivation path. Even though the check covers both, any change that is made to taproot that makes taproot entries skip the check would slip through because they are not being asserted here.

Thanks for pointing this out! I’ve added tests for tap_key_origins as well.