Extended Public Key (xpub)

Anna guarda su cartera de Bitcoin en un dispositivo físico y quiere comprobar en el teléfono si un cliente ha pagado. Transfiere al teléfono la configuración pública de la cuenta elegida, que incluye su xpub, pero ninguna clave privada. El teléfono funciona entonces como una Watch-only Wallet: observa las direcciones correspondientes, prepara otras nuevas y construye transacciones sin firmar. Para gastar sigue haciendo falta la firma del dispositivo que guarda las claves secretas. Del mismo modo, una tienda puede generar distintas direcciones para los pedidos sin almacenar claves de gasto en el servidor. Esta separación limita las consecuencias de una intrusión, pero no resuelve todo: un atacante podría mostrar su propia dirección a los clientes para un nuevo pago. [1] [5]

Entregas una dirección Bitcoin corriente a quien debe pagarte. Un xpub ofrece una vista mucho más amplia. Quien conoce el xpub de una cuenta y sus reglas de direcciones puede calcular direcciones de recepción y de devolución del cambio, y relacionar sus historiales y saldos. Esto abarca la rama derivable, no automáticamente todas las cuentas de la cartera. Si lo entregas a un servicio contable o a un explorador externo, puede conservarlo y observar pagos futuros. Desconectar la aplicación no revoca la copia ya entregada. Para recibir un pago suele bastar con dar una dirección; concede un acceso más amplio solo cuando tenga un propósito real. [1] [5]

Una cartera BIP32 crea un árbol de claves desde un único punto de partida. Una rama es aquí un grupo de claves derivadas, no una parte de la red o de la cadena de bloques. Un xpub solo puede avanzar hacia abajo por pasos llamados non-hardened. El otro tipo, Hardened Derivation, requiere datos privados y establece una frontera que el xpub solo no puede cruzar. La estructura habitual BIP44 coloca esa frontera antes de cada cuenta. Por eso exportar el xpub de una cuenta no revela por sí solo las otras. También importa la profundidad de exportación: el xpub de la rama de recepción permite observar menos que el de toda la cuenta, que normalmente incluye el cambio. [1] [6]

Las mismas claves públicas pueden producir distintas direcciones Bitcoin según las reglas aplicadas. Una salida de transacción registra una cantidad y las condiciones para gastarla después. La aplicación necesita saber el tipo de salida de la cartera, como Native SegWit o Taproot, y qué rama e índices debe derivar. Los prefijos ypub y zpub de SLIP-0132 pueden orientar sobre el tipo de dirección, pero no describen toda la cartera. Output Descriptor es más preciso: registra las claves y reglas que crean las direcciones y las condiciones de gasto. Puede incluir el origen de la clave, la ruta de derivación y una suma de comprobación para detectar errores de escritura. Esta comprueba el texto, no la fiabilidad de quien lo envió. No todos los descriptores son solo públicos: algunos contienen claves privadas, así que distínguelos antes de compartirlos. [2] [3] [4]

Comprueba primero la red, la cuenta elegida, el tipo de dirección y la ruta de derivación: las instrucciones que sitúan la clave en el árbol. Compara varias direcciones de recepción con la cartera original y, si usas un dispositivo físico, verifica su pantalla fiable según el procedimiento del fabricante. Un nombre de cuenta idéntico no basta. Un saldo cero no implica necesariamente pérdida de fondos: quizá estés observando otra cuenta, otro tipo de dirección o un rango de índices demasiado pequeño. No lo intentes resolver introduciendo palabras de recuperación en una web cualquiera. Para consultar, busca una exportación de configuración pública, no la Seed Phrase ni un xprv, la clave privada extendida. [4] [5]

Un xpub solo no es una clave de firma. Sin embargo, BIP32 tiene una relación importante: un xpub padre, llamado parent xpub en la documentación, junto con la clave privada de un descendiente non-hardened permite recuperar la clave privada padre. Si el descendiente está más lejos, todos los pasos intermedios deben ser non-hardened y hay que conocer la ruta correspondiente para calcularla. No se trata de robar con solo conocer una dirección. La combinación peligrosa es la vista pública filtrada y una clave secreta filtrada de la misma rama. Puede dar al atacante las demás claves bajo ese padre. Las fronteras hardened separan cuentas, pero no protegen una clave privada ya expuesta. [1]

Una cartera Multisig puede exigir dos firmas de tres claves. Pero no basta con saber cuáles son las dos claves que puedes recuperar. Para reconstruir las condiciones de gasto correctas también necesitas los datos públicos de las demás claves participantes, su disposición, el número de firmas exigido y las reglas de derivación. Junto a los respaldos secretos, conserva la configuración de la cartera, por ejemplo un descriptor público con todos los xpub necesarios. No autoriza a gastar, pero puede ser esencial para recuperar el acceso. El master fingerprint, ocho caracteres hexadecimales que identifican la clave inicial, ayuda a relacionar la configuración. No es un certificado de identidad único: claves diferentes pueden compartir fingerprint. [4] [5]

Una clave pública verifica firmas creadas con la clave privada correspondiente. BIP32 añade un chain code, un valor de 32 bytes para derivar otras claves. Juntos forman una clave pública extendida. Su representación portable incluye además la versión y la posición en el árbol: profundidad, fingerprint del padre inmediato y número del hijo. Eso no equivale a la ruta completa desde la primera clave de la cartera. Un xpub no es, por tanto, una dirección individual ni una contraseña de cuenta, y no contiene una lista de transacciones. La cartera observadora las busca en la cadena para las direcciones correspondientes. [1]

CKDpub, la función de BIP32, toma la clave pública padre, su chain code y el índice del hijo. Mediante HMAC-SHA512, un cálculo criptográfico sobre esas entradas, prepara otra clave pública y un nuevo chain code. Los índices derivables públicamente van de 0 a 2³¹−1. Los hardened comienzan en 2³¹ y suelen marcarse con apóstrofo o h en las rutas; CKDpub desde un xpub no puede derivarlos. Repetir pasos permitidos produce descendientes, no hermanos ni antepasados de la clave exportada. Si aparece un resultado inválido poco frecuente descrito en BIP32, la implementación pasa al siguiente índice. Un usuario normal no necesita hacer estos cálculos: lo importante es transferir correctamente la configuración. [1]

Antes de codificarlo como texto, el registro estándar BIP32 ocupa 78 bytes: versión 4, profundidad 1, fingerprint padre 4, número del hijo 4, chain code 32 y datos de clave 33. Base58Check añade una suma de comprobación y convierte el registro en 111 caracteres. La versión pública de la red principal empieza por xpub y la de prueba por tpub; sus equivalentes privados empiezan por xprv y tprv. Tpub no significa Taproot. El prefijo procede de los bytes de versión y no describe todas las reglas de direcciones. Al importar, el software debe validar también la clave pública, no solo sus primeras letras o su longitud. [1] [3]