Un xpub no es una dirección Bitcoin ni una clave de firma. Exporta un nodo del árbol BIP32 para que una wallet watch-only o un servidor de cobros genere claves y direcciones inferiores. Normalmente no permite gastar, pero sí observar la rama; el significado de las direcciones depende además del derivation path y la script policy.
BIP32 representa la clave pública extendida como el punto público K unido a un chain code de 32 bytes. La serialización incluye además version bytes, depth, parent fingerprint y child number. No es una dirección ni una clave pública aislada, sino un nodo jerárquico con datos para continuar su rama pública.
CKDpub combina public key, chain code e índice mediante HMAC-SHA512. Para índices de 0 a 2³¹−1 produce una child public key y un nuevo chain code, permitiendo generar direcciones receive y change sin secreto de firma. Solo deriva descendientes del nodo exportado, no hermanos ni antepasados.
Los índices hardened empiezan en 2³¹ y se escriben con apóstrofo o h. Su cálculo requiere datos privados, por lo que CKDpub falla desde un parent xpub. Las wallets suelen endurecer purpose, coin type y account y exportar después el account xpub, aislando las demás cuentas hardened.
La serialización BIP32 ocupa 78 bytes: versión, depth, parent fingerprint, child number, chain code y 33 bytes de key material. Base58Check la convierte en 111 caracteres; la versión pública mainnet empieza por xpub y testnet por tpub. El prefijo proviene de los version bytes.
El xpub no especifica si las claves forman scripts P2PKH, wrapped SegWit, native SegWit, Taproot o multisig, ni siempre dónde está el nodo. SLIP-0132 introdujo ypub, zpub y otras versiones como pistas, mientras un descriptor declara de forma explícita script, fingerprint, path, xpub, wildcard y checksum.
Quien posee un account xpub puede calcular public keys receive y change no hardened y correlacionar transacciones y saldos. Entregarlo a software fiscal o pegarlo en un block explorer crea una vista duradera de la cuenta y puede unir datos de red o identidad con la historia on-chain.
Un xpub solo no firma. La excepción crítica de BIP32: parent xpub más una private key de un descendiente no hardened permite recuperar la parent private key y toda esa rama. Por eso el xpub es dato sensible y los límites de account se hacen hardened.
Una wallet watch-only monitoriza el xpub, prepara una transacción unsigned y la pasa al dispositivo firmante. Un comercio genera direcciones únicas sin guardar xprv. Esto reduce el robo directo tras comprometer el servidor, no la vigilancia; la dirección de cobro debe verificarse en una pantalla confiable.
En multisig, el seed propio no describe toda la wallet: la recuperación exacta requiere public keys de cosigners, threshold, script type y derivation data. Un descriptor conserva la policy mejor que xpubs sueltos. El master fingerprint ayuda a emparejar claves, pero puede colisionar y no prueba identidad.
Antes de importar, confirme network, account, derivation path, script type, ramas receive/change y rango de índices. Compare xpub o descriptor en un dispositivo confiable y confronte varias direcciones derivadas con la wallet original; no use un explorer externo sin aceptar conscientemente la pérdida de privacidad. Fuentes: BIP 32 — Hierarchical Deterministic Wallets; BIP 380 — Output Script Descriptors General Operation; SLIP-0132 — Registered HD Version Bytes; Bitcoin Core — Output Descriptors; Trezor — What Is a Public Key (XPUB)?.
Para obtener la imagen más completa, lee esta entrada junto con HD Wallet, Watch-only Wallet, Privacidad en Bitcoin, Derivation Path, Bitcoin, Output Descriptor. También enlazan con esta entrada HD Wallet, Cold Storage, Watch-only Wallet, Output Descriptor.