What happened
On 15 August 2026, Bitcoin Core merged
pull request #32784, which adds a
derivehdkey RPC. The
release note
describes it as a way "to obtain an xpub or xprv for a derivation path with at least one
hardened step from an HD key known to the wallet", to be used "to coordinate a multisig
setup, where each signer shares an xpub using a different derivation path than the default
single-signature descriptors."
What it changes
An extended public key, written xpub, is a public key bundled with a chain code. The
two together let anyone compute every ordinary child key below that point without ever
touching a private key. That is what makes watch-only wallets possible, and it is the unit
in which multisig participants introduce themselves: each
signer hands over one xpub, and the descriptor assembled from them tells every participant
what the addresses are.
Which branch that xpub comes from matters, because exporting the branch that already backs
your single-signature wallet entangles the two.
BIP-87 exists for this
reason, and m/87h/0h/0h is the example in the new command's
help text. Core
could always produce xpubs. Producing one at a path of your choosing meant building a
descriptor for it first, or handling master key material outside the wallet.
The requirement worth understanding is the hardened one. The RPC rejects any path without a hardened step: "Derivation path requires at least one hardened step". A hardened child cannot be computed from its parent's public key, only from the parent's private key, which is the property that stops a leaked xpub from walking upwards. So even when all you want back is a public key, the wallet must be unlocked to make it, and the help text says so plainly: "Derivation uses wallet private key material." Watch-only wallets are refused outright.
What it does not change
An xpub is not a harmless thing to hand out. Whoever holds one can derive every address under it and watch that branch forever, backwards and forwards. What they cannot do is spend. Those two facts are the entire risk profile of an xpub, and they get conflated in both directions constantly.
The path only has to contain a hardened step, not end on one. Ask for an xprv at an unhardened child of a node whose xpub you have already shared, and the pair reconstructs that node's private key. Review raised exactly this, and the author declined to block it, on the grounds that "anyone who obtains xprv's should be careful." That is a fair position and also a sharp edge.
And this is merged, not released. The note is sitting in doc/ waiting for the next major
version; no shipped Bitcoin Core has the command.
Context
Two days earlier, in the proposal repository rather than the client, chain code delegation advanced to Deployed. It solves the opposite half of the same problem: letting a co-signer sign an input without being handed an xpub at all. The two changes point in different directions from the same observation, which is that the xpub is simultaneously the coordination format of multisig and its largest privacy leak. One makes handing one over deliberate. The other removes the need to.