HD wallets, BIP-32 y xpub: claves extendidas, huellas y prefijos

Una seed, un árbol: qué problema resolvía BIP-32

Antes de BIP-32, cada clave de una billetera (wallet) salía del azar. Había que guardar la copia de seguridad cada cierto tiempo, y las claves nuevas que se generaban después de la copia no estaban en ella. El cliente de referencia lo suavizaba con un pool de reserva de 100 claves por defecto, de modo que la copia hacía falta cuando el pool se agotaba, no tras cada transacción (BIP-32, apartado «Motivation», consultado el 7 de octubre de 2026). Aun así, cada copia caducaba.

BIP-32, de Pieter Wuille y con estado Deployed, resuelve esto con una idea: todas las claves salen de una sola semilla mediante una función determinista. Si se conserva la semilla, se puede volver a calcular cualquier clave. Para ello se parte de la idea original de Gregory Maxwell y de la implementación de ese esquema en Armory, de Alan Reiner (BIP-32, «Acknowledgements»).

El propio BIP da un segundo motivo, y es el que explica la xpub: una tienda web podría generar direcciones nuevas en el servidor usando solo claves públicas, sin que ese servidor guarde ninguna clave privada. Bitcoin Core adoptó BIP-32 en la 0.13.0 (23 de agosto de 2016), con la ruta m/0'/0'/k', todos los niveles endurecidos, el último también (notas de la versión 0.13.0 y doc/bips.md de Core, consultados el 7 de octubre de 2026).

Un matiz sobre el «árbol»: no es infinito. Cada nodo tiene 2³¹ hijos normales y 2³¹ endurecidos, 2³² en total (BIP-32). Es un número enorme, pero finito.

⚠️ Vectores de prueba comprometidos: las huellas 73c5da0a, b4e3f5ed y 7ef32bdb de esta entrada salen de la frase pública de prueba de BIP-39, «abandon … about», con passphrase vacía y con «TREZOR». Cualquiera conoce sus claves privadas: nunca guardes fondos en ellas. Esta entrada no muestra ninguna clave extendida.

Clave extendida: una clave más un chain code

Una clave extendida es una clave más un chain code de 32 bytes, «an extra 256 bits of entropy» según BIP-32. La privada se escribe (k, c) y la pública (K, c), con K = point(k). El chain code es el mismo en las dos versiones. Sirve para que los hijos no dependan solo de la clave: sin él, quien conociera una clave pública podría calcular todos sus hijos.

El chain code no es una clave privada. No firma nada. Es un secreto que acompaña a la clave, y sin él no se derivan hijos.

La clave extendida maestra, m, sale de la semilla con un solo paso: I = HMAC-SHA512 con clave «Bitcoin seed» y la semilla como dato. Los 32 bytes de la izquierda son la clave privada maestra y los 32 de la derecha, el chain code maestro. BIP-32 admite semillas de 128 a 512 bits y aconseja 256. BIP-39 entrega 512 bits, y cómo se obtienen desde las palabras queda en esa entrada.

Cómo nace un hijo

Un hijo es un HMAC más una suma. Para el hijo número i, se calcula HMAC-SHA512 usando como clave el chain code del padre. La mitad izquierda del resultado, I_L, se suma a la clave privada del padre (módulo n) y da la clave privada del hijo. La mitad derecha, I_R, es el chain code del hijo (BIP-32, CKDpriv).

Lo único que cambia entre un hijo normal y uno endurecido es qué entra en el HMAC como dato:

• Hijo normal (índices 0 a 2³¹-1): entra la clave pública del padre y el índice.
• Hijo endurecido (índices 2³¹ a 2³²-1): entra la clave privada del padre y el índice.

De ahí sale todo lo útil de la xpub. Quien tiene la clave pública y el chain code del padre, es decir, la xpub, puede calcular el mismo I_L de un hijo normal. Y como point(I_L + k_padre) = point(I_L) + K_padre, obtiene también la clave pública del hijo sin conocer ninguna privada. Por eso una xpub genera direcciones.

Con un hijo endurecido, en cambio, el HMAC pide la clave privada del padre. Sin ella no se puede calcular, y la derivación pública devuelve «failure» (BIP-32, CKDpub). «Endurecido» no significa «más cifrado»: solo cambia lo que entra en el HMAC.

La notación de la ruta (el apóstrofo, h y H), los niveles de BIP-44, 49, 84 y 86 y el diagnóstico de un saldo cero tras restaurar están en rutas de derivación, y aquí no se repiten.

La fuga: una xpub y una clave privada descendiente

Una xpub sola no deja gastar. Pero con una clave privada que descienda de ella sin endurecer, la cosa cambia. BIP-32 lo dice así: conocer la xpub de un padre más cualquier clave privada no endurecida que descienda de él equivale a conocer la xprv del padre, y con ella todas las claves, privadas y públicas, que cuelgan de él (BIP-32, «Implications», consultado el 7 de octubre de 2026).

La cuenta, en palabras. El atacante tiene la xpub del padre, es decir, su clave pública K y su chain code c. Para cualquier índice i puede calcular el I_L que el padre usó, porque con un hijo normal solo entra K. Si además tiene la clave privada del hijo, k_i, despeja: k_padre = k_i − I_L (módulo n). Con k_padre y el c que ya traía la xpub, ya tiene la xprv.

El índice i no está protegido. El propio BIP avisa de que, dada la xpub del padre y la clave pública de un hijo, es fácil averiguar i. Recorrer los índices habituales cuesta poco.

La palabra clave del BIP es «descending»: vale cualquier descendiente, no solo los hijos directos. La clave de una dirección …/0/5 es nieta de la xpub de cuenta. El cálculo se aplica dos veces: primero se recupera el nodo …/0 y luego la cuenta. La xpub del nodo intermedio sale de la xpub de cuenta por derivación pública.

El cálculo se detiene en el primer nivel endurecido hacia arriba. En las rutas BIP-44, 49, 84 y 86, ese nivel es account'. Por eso una fuga a nivel de cuenta o inferior no compromete la clave maestra ni las demás cuentas. BIP-32 lo da como razón de que existan los hijos endurecidos y de que se usen en ese nivel.

La consecuencia práctica es esta. Quien ha compartido la xpub de una cuenta no debe sacar nunca de esa cuenta una clave privada suelta, por ejemplo exportando la clave WIF de una dirección. En ese momento la xpub compartida deja de ser «solo lectura». El peligro aparece cuando las dos piezas acaban en las mismas manos. Quien tenga la xpub y consiga además esa clave privada, por la vía que sea, tiene la cuenta entera. Y la xpub suele estar en más sitios de los que parece: en el programa que vigila la billetera, en el coordinador, en cualquier servicio al que se le diera.

Qué revela una xpub y qué no

Lo que revela una xpub:

• Las claves públicas de todos sus descendientes no endurecidos, pasados y futuros.
• Con el tipo de script, todas las direcciones de esa rama, su saldo y su historial.
• Con una xpub de cuenta, las dos cadenas: recepción (/0) y cambio (/1). Se ve también el cambio, así que cada gasto aparece completo.
• La profundidad, la huella del padre y el último índice, porque van serializados.

Lo que no revela:

• Ninguna clave privada. No permite firmar.
• Los hijos endurecidos de ese nodo.
• Ni las otras cuentas ni los otros purpose: otro tipo de script es otra rama endurecida.
• Las billeteras con otra passphrase, que son otra semilla.
• La huella maestra y la ruta completa (salvo en una xpub que cuelgue directamente de m).
• Qué tipo de script usar.

Dos matices. El primero es la diferencia entre cuenta y cadena externa. Una xpub de la cadena …/0, como la del caso «unsecure money receiver» de BIP-32, enseña los pagos que entran y cuándo se gastan esas monedas, pero no el cambio que vuelve por /1. Por eso, según el BIP, quien asalte ese servidor «will not (trivially) be able to distinguish outgoing transactions». Una xpub de cuenta enseña además el cambio, y con él cuánto se pagó en cada gasto. Compartir la de cuenta con un contable es darle todo.

El segundo: para mostrar el historial a partir de una xpub, el software tiene que preguntar a un servidor o a un nodo por esas direcciones. Entregar la xpub a un servicio de terceros es entregarle todo lo de la primera lista. BIP-32 separa los dos riesgos: filtrar una clave privada da acceso a los fondos y filtrar una clave pública puede costar privacidad. Con una xpub hay más en juego, porque junto a una clave privada descendiente equivale a la xprv, y por eso el BIP pide tratar las claves públicas extendidas con más cuidado que las normales (BIP-32, «Implications»). Más sobre esto en reutilización de direcciones.

Dentro de una xpub: 78 bytes y dos huellas

Una clave extendida serializada mide 78 bytes (BIP-32, «Serialization format»):

• 4 bytes de versión. En mainnet, 0x0488B21E para la pública y 0x0488ADE4 para la privada. En testnet, 0x043587CF y 0x04358394.
• 1 byte de profundidad (0x00 en la maestra).
• 4 bytes con la huella del padre (0x00000000 en la maestra).
• 4 bytes con el número de hijo.
• 32 bytes de chain code.
• 33 bytes de clave: la pública comprimida en una xpub, o 0x00 más los 32 bytes de la privada en una xprv.

Con el checksum de doble SHA-256 y la codificación Base58 salen 111 caracteres, que empiezan por xpub o xprv en mainnet y por tpub o tprv en testnet. Al importar una xpub, el software debe comprobar que el punto está en la curva. El vector de prueba 5 de BIP-32 recoge casos inválidos, entre ellos una profundidad cero con una huella de padre distinta de cero.

Hay dos huellas y se confunden. La huella maestra son los primeros 4 bytes del Hash160 de la clave pública de m: es lo que usan los descriptores y las PSBT para saber de qué semilla sale una clave. Para la frase de prueba «abandon … about» con passphrase vacía vale 73c5da0a, y con la passphrase «TREZOR», b4e3f5ed. Las dos se pueden ver en el explorador de rutas de derivación. Su uso para detectar una passphrase equivocada está explicado en rutas de derivación.

La huella del padre va dentro de cada clave extendida serializada. Es solo «a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions» (BIP-32). Como son 32 bits, puede coincidir entre dos claves distintas. No identifica una semilla.

De ahí un detalle que sorprende. Una xpub de cuenta BIP-84 no trae la huella maestra ni la ruta. En el vector de BIP-84, la zpub de cuenta lleva profundidad 3, índice 0x80000000 (el 0' de la cuenta) y huella del padre 7ef32bdb, la del nodo m/84'/0', que no es la maestra 73c5da0a. Por eso un descriptor añade aparte el origen [huella_maestra/ruta]: BIP-380 pide «exactly 8 hex characters for the fingerprint of the key where the derivation starts», que normalmente es la maestra. Y BIP-380 pide que, al exportar sin claves privadas, se derive la xpub en el último paso endurecido y se añadan esos pasos al origen.

Lo mismo hacen las PSBT (BIP-174): cada clave va con la huella maestra y la ruta, y con eso un firmante puede ver si una salida es suya. Puedes seguir la derivación con el explorador de rutas de derivación, que trabaja solo con la frase de prueba.

xpub, ypub, zpub y tpub: la misma clave con otros bytes

Los 78 bytes de una zpub son idénticos a los de la xpub de la misma clave, salvo los 4 de versión. El checksum Base58Check se recalcula. Convertir una zpub en xpub no cambia ni la clave ni las direcciones.

Los prefijos nacieron para que la clave «dijera» el script. BIP-49 definió 0x049d7cb2 (ypub) y BIP-84 definió 0x04b24746 (zpub). SLIP-132, de Clark Moody (8 de febrero de 2018), los recoge en un registro porque la versión original de BIP-49 mantenía el prefijo xpub y no había forma de saber qué derivación correspondía (SLIP-0132, consultado el 7 de octubre de 2026). Para claves únicas:

Prefijo (bytes de versión)	Script	Ruta
xpub (0x0488b21e)	P2PKH o P2SH	m/44'/0'
ypub (0x049d7cb2)	P2WPKH dentro de P2SH	m/49'/0'
zpub (0x04b24746)	P2WPKH	m/84'/0'
tpub (0x043587cf)	P2PKH o P2SH	m/44'/1'
upub (0x044a5262)	P2WPKH dentro de P2SH	m/49'/1'
vpub (0x045f1cf6)	P2WPKH	m/84'/1'

Las tres primeras filas son de mainnet y las tres últimas, de testnet. El registro trae además prefijos de multifirma (Ypub, Zpub y sus equivalentes de testnet), sin ruta asociada. Y no tiene ninguna fila para P2TR.

Esa es la primera grieta. BIP-86 no definió bytes de versión nuevos y usa xpub en sus vectores. La segunda: una multifirma necesita además umbral y orden de claves, y eso no cabe en un prefijo. La tercera: la ruta no viaja en la clave. BIP-380 lo llama «layer violation» («key derivation should be separate from script type meaning») y lo resuelve declarando el script (wpkh(), sh(wpkh()), tr(), wsh()) y la ruta dentro del descriptor. En un descriptor solo cabe xpub, o tpub en testnet.

Bitcoin Core refleja esto. Sus parámetros de red solo definen los prefijos de xpub y xprv en mainnet y de tpub y tprv en testnet3, testnet4, signet y regtest (src/kernel/chainparams.cpp, consultado el 7 de octubre de 2026). Nunca ha tenido ypub ni zpub. Eso no significa que SLIP-132 esté retirado: sigue en estado Active, sin nota de obsolescencia. Lo que ha pasado es que los descriptores lo hacen innecesario.

Para Core, desde la 0.17.0 hay descriptores en RPC, desde la 0.21.0 las billeteras de descriptores usan rutas BIP-44, 49 y 84 por defecto, y desde la 23.0 también BIP-86 (doc/bips.md de Core, consultado el 7 de octubre de 2026).

Qué significa esto para ti

Comparte una xpub solo con software que controles. Es pública en el sentido de que no gasta, pero revela todo el historial de la cuenta, entradas, salidas y cambio, y no se puede retirar una vez entregada. Un servicio de terceros que la reciba lo ve todo. Si un diseño te obliga a darla, como una multifirma con un servicio, ese servicio ve el historial: cuéntalo como un coste.

Si ya compartiste la xpub de una cuenta, no exportes claves privadas sueltas de esa cuenta. Ni una. Esa pareja equivale a la xprv de la cuenta. Las demás cuentas y la clave maestra quedan a salvo, pero los fondos de esa cuenta no. Si ya ocurrió y la clave privada pudo salir de tu control, trata la billetera como expuesta: crea una nueva, con otra seed, y pasa ahí los fondos (los pasos, en «Cuándo y cómo cambiar de billetera», dentro de recuperar tu billetera).

Si tu billetera te da una zpub o una ypub, es la misma clave con otro prefijo. Un descriptor solo admite xpub (o tpub), así que, si lo escribes a mano, hay que cambiar el prefijo. Las billeteras que exportan el descriptor ya lo hacen solas. Si lo conviertes tú, hazlo en tu propio equipo, con un programa de confianza y sin conexión, no con un conversor en una web: quien recibe la zpub ve todo tu historial. Para copias de seguridad, guarda el descriptor y no solo la xpub: dice el script y la ruta que la clave no lleva.

Y recuerda lo básico. La seed phrase, y la passphrase si la usas, es lo que lo controla todo. La xpub es solo la ventana por la que se ve.