Qué pasó
El 15 de agosto de 2026, Bitcoin Core integró el
pull request #32784, que agrega un RPC
llamado derivehdkey. La
nota de versión
lo describe como una manera "de obtener una xpub o una xprv para una ruta de derivación con
al menos un paso endurecido a partir de una clave HD conocida por la wallet", pensada para
"coordinar un esquema multisig, donde cada firmante comparte una xpub usando una ruta de
derivación distinta de la de los descriptores de firma simple por defecto."
Qué cambia
Una clave pública extendida, escrita xpub, es una clave pública acompañada de un chain
code. Las dos juntas permiten calcular todas las claves hijas ordinarias por debajo de ese
punto sin tocar nunca una clave privada. Eso es lo que hace posibles las wallets de solo
lectura, y es la unidad con la que se presentan los participantes de un
multisig: cada firmante entrega una xpub, y el descriptor
que se arma con todas ellas le dice a cada participante cuáles son las direcciones.
De qué rama sale esa xpub importa, porque exportar la rama que ya respalda la wallet de firma
simple mezcla las dos.
BIP-87 existe por ese
motivo, y m/87h/0h/0h es el ejemplo que aparece en el
texto de ayuda
del nuevo comando. Core siempre pudo producir xpubs. Producir una en la ruta elegida exigía
construir antes un descriptor para ella, o manipular material de la clave maestra fuera de la
wallet.
El requisito que conviene entender es el del paso endurecido. El RPC rechaza cualquier ruta que no lo tenga: "Derivation path requires at least one hardened step". Una hija endurecida no se puede calcular desde la clave pública de su padre, solo desde la clave privada, y esa es justamente la propiedad que impide que una xpub filtrada camine hacia arriba. Así que aunque lo único que se quiera de vuelta sea una clave pública, la wallet tiene que estar desbloqueada para fabricarla, y el texto de ayuda lo dice sin rodeos: "Derivation uses wallet private key material." Las wallets de solo lectura quedan rechazadas directamente.
Qué no cambia
Una xpub no es algo inofensivo de entregar. Quien la tenga puede derivar todas las direcciones por debajo de ella y observar esa rama para siempre, hacia atrás y hacia adelante. Lo que no puede hacer es gastar. Esos dos hechos son todo el perfil de riesgo de una xpub, y se confunden en ambas direcciones de manera constante.
La ruta solo tiene que contener un paso endurecido, no terminar en uno. Si se pide una xprv en una hija no endurecida de un nodo cuya xpub ya se compartió, el par reconstruye la clave privada de ese nodo. La revisión planteó exactamente eso, y el autor decidió no bloquearlo, con el argumento de que "anyone who obtains xprv's should be careful." Es una posición defendible y también un filo.
Y esto está integrado, no publicado. La nota espera en doc/ a la próxima versión mayor:
ningún Bitcoin Core lanzado tiene el comando.
Contexto
Dos días antes, en el repositorio de propuestas y no en el cliente, chain code delegation avanzó a Deployed. Resuelve la mitad opuesta del mismo problema: permite que un co-firmante firme un input sin recibir ninguna xpub. Los dos cambios apuntan en direcciones distintas a partir de la misma observación, que es que la xpub es a la vez el formato de coordinación del multisig y su mayor fuga de privacidad. Uno hace que entregarla sea deliberado. El otro elimina la necesidad de hacerlo.