-snip- that is not possible because extended keys are shielded from that with chain code.
I think you misunderstood the "
chain code" as some sort of magic privacy improving thingy.
It's just the extra bits result from when a parent master/extended key is passed through HMAC SHA-512 to derive a child key or child extended key.
So, the first 256-bit is the private/public key and the next 256-bit is the chain code.
Documents explain that it's required to derive children keys from the parent.
So in term, even if the first part is exposed (
the private/public key), it can't be used solely to derive the children. (
this is probably what you've read)
But if you take those into account with the current standards, there's no known wallet implementation that use an extended key's public key part to be encoded into an address displayed by the wallet.
The standards use the "
youngest" children keys, e.g.: at
m/purpose'/coin'/account'/chain/address_index for the addresses.
If not the standard paths, the addresses are at least at the lower level in the derivation path which isn't an extended key where the other addresses are derived from.
In other words, the addresses that you're using to send/receive are derived from public keys without any children that can be linked to/by it.
And also, if an xpub/xprv is exposed, it's essentially the the private/public key and chain code parts bundled in one already.
Wallets do not export those separately, so in this case, the chain code doesn't shield the base58check-encoded xprv/xpub in any way.
In reality, other nodes or people initially can't link your addresses because those child keys are results of that pseudo-random and one-way function that I mentioned.
They can't link your other addresses without the parent extended public/private key or without the user doing any privacy-reducing practices.