feat: accept bare extended public keys as scan input - #31
Merged
Conversation
expand_input() detects bare xpub/tpub/ypub/zpub/upub/vpub inputs via base58check version bytes. SLIP-132 keys are re-encoded with canonical version bytes and mapped to their script type; ambiguous xpub/tpub expand to pkh, sh(wpkh), wpkh, and tr candidates. Everything else passes through untouched.
analyze_descriptors expands each raw input through expand_input before normalization, so a bare xpub/tpub (or SLIP-132 key) becomes importable descriptor candidates. Candidates without activity are harmless watch- only imports. Covered by a regtest e2e test feeding a bare tpub with history into the engine.
The CLI --descriptor flag and the API descriptor/descriptors fields accept bare extended public keys through the engine's expand_input; help text updated and an HTTP test pins the API contract.
Review follow-ups on xpub scan input: - expand_input now returns Result and rejects extended PRIVATE keys (xprv/tprv/yprv/zprv/uprv/vprv and SLIP-132 multisig Yprv/Zprv/ Uprv/Vprv) with a dedicated error that never echoes the input; previously a pasted xprv travelled to getdescriptorinfo and came back verbatim inside DescriptorNormalization, which the CLI prints and the API returns. - Defence in depth: the DescriptorNormalization Display now redacts any [xtyzuvYZUV]prv-prefixed alphanumeric run. - A derivation suffix on a bare key (xpub.../0/*) is now split off before decoding and re-attached inside the wrappers, matching what the frontend already sends. - SLIP-132 multisig public keys (Ypub/Zpub/Upub/Vpub) are rejected with guidance to provide the wallet descriptor instead. - xpub integration tests use expect over bare unwrap.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Descriptors are precise but hostile as a user input: most wallets only export an extended public key. This makes a bare xpub (or any SLIP-132 variant) a first-class scan input across engine, CLI and API, entering through the existing descriptor fields with no schema change.
How it works:
Tests: round-trip unit tests against the BIP-32 vector-1 xpub for every SLIP-132 conversion, rejection tests for all private variants asserting the key never appears in the error text, and an end-to-end regtest test that feeds a bare tpub and finds the wallet's activity through the ambiguous-expansion path. Verified on mainnet: a bare xpub scan derived and recognized 8000 addresses across the four candidates in about two seconds; a real LND account zpub produced a full, correct wallet audit. Suite 57/57 with clippy -D warnings clean.