Context
737918d (landed via #632) replaced the BitkitCore.serializedExtendedPubkey FFI call in WatchOnlyAccountClaimCodec.serializedXpub with a local base58check decoder plus a secp256k1 point check on the trailing compressed key.
Discussion on the PR records the upstream state at the time this landed (2026-07-28): dd99b46d was still not on bitkit-core master, and neither release cut since carried it — v0.4.4 predates it and v0.5.3 was cut from the Boltz branch. So there was no tag with both serializedExtendedPubkey and the Boltz module. Re-check that before assuming this is still blocked.
This was a workaround, not a preference. serializedExtendedPubkey only ever shipped in bitkit-core v0.4.2, a tag cut from a branch that never merged to bitkit-core master. No later release (0.4.3, any 0.5.x, or master) carries it, so depending on it pinned this repo to a dead-end tag and blocked every bitkit-core upgrade — including the 0.5.3 bump that #632 needs for the Boltz module.
What to do
Once bitkit-core lands dd99b46d "feat: expose serialized extended public keys" on master and cuts a release carrying both that symbol and the Boltz module:
The testSerializedXpub* cases in BitkitTests/WatchOnlyAccountServiceTests.swift pin the behaviour byte-for-byte against bitkit-core's own vectors, so they should pass unchanged across the swap and are the check that the revert is faithful. Keep them.
Why it is worth reverting
The local decoder is byte-exact on the tested vectors but is a looser validator than rust-bitcoin's Xpub::from_str: it does not check the 4-byte version prefix, so any 78-byte base58check payload with a valid curve point is accepted (ypub/zpub or arbitrary version bytes), where the FFI path would reject them. An xprv is still correctly rejected, since its 0x00 key prefix fails secp256k1_ec_pubkey_parse. Accepting both xpub and tpub is intentional and pinned by tests.
If the revert cannot happen by 2.5.0, consider whitelisting the known mainnet/testnet version prefixes in the local decoder as a stopgap.
Files
Bitkit/Services/WatchOnlyAccountService.swiftBitkitTests/WatchOnlyAccountServiceTests.swift
References
Context
737918d(landed via #632) replaced theBitkitCore.serializedExtendedPubkeyFFI call inWatchOnlyAccountClaimCodec.serializedXpubwith a local base58check decoder plus a secp256k1 point check on the trailing compressed key.Discussion on the PR records the upstream state at the time this landed (2026-07-28):
dd99b46dwas still not on bitkit-coremaster, and neither release cut since carried it — v0.4.4 predates it and v0.5.3 was cut from the Boltz branch. So there was no tag with bothserializedExtendedPubkeyand the Boltz module. Re-check that before assuming this is still blocked.This was a workaround, not a preference.
serializedExtendedPubkeyonly ever shipped in bitkit-core v0.4.2, a tag cut from a branch that never merged to bitkit-coremaster. No later release (0.4.3, any 0.5.x, or master) carries it, so depending on it pinned this repo to a dead-end tag and blocked every bitkit-core upgrade — including the 0.5.3 bump that #632 needs for the Boltz module.What to do
Once bitkit-core lands
dd99b46d "feat: expose serialized extended public keys"onmasterand cuts a release carrying both that symbol and the Boltz module:serializedXpubto callBitkitCore.serializedExtendedPubkeybase58CheckDecode,base58Decode,isValidCompressedPublicKey,base58Alphabet, and theimport secp256k1added for themTODOinBitkit/Services/WatchOnlyAccountService.swiftThe
testSerializedXpub*cases inBitkitTests/WatchOnlyAccountServiceTests.swiftpin the behaviour byte-for-byte against bitkit-core's own vectors, so they should pass unchanged across the swap and are the check that the revert is faithful. Keep them.Why it is worth reverting
The local decoder is byte-exact on the tested vectors but is a looser validator than
rust-bitcoin'sXpub::from_str: it does not check the 4-byte version prefix, so any 78-byte base58check payload with a valid curve point is accepted (ypub/zpub or arbitrary version bytes), where the FFI path would reject them. Anxprvis still correctly rejected, since its0x00key prefix failssecp256k1_ec_pubkey_parse. Accepting both xpub and tpub is intentional and pinned by tests.If the revert cannot happen by 2.5.0, consider whitelisting the known mainnet/testnet version prefixes in the local decoder as a stopgap.
Files
Bitkit/Services/WatchOnlyAccountService.swiftBitkitTests/WatchOnlyAccountServiceTests.swiftReferences
737918d—fix: decode xpub locally instead of stranded bitkit-core symboldd99b46d—feat: expose serialized extended public keys