---
title: "Cartera jerárquica determinista (HD)"
description: "Descubre cómo una cartera HD deriva un árbol de claves a partir de una sola semilla, en qué se diferencian la derivación reforzada y la normal, y qué debe conservar una copia de seguridad completa y verificable."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Cartera jerárquica determinista (HD)
> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
## Respuesta directa
Una cartera jerárquica determinista (HD) deriva un árbol reproducible de pares de claves criptográficas a partir de una única semilla raíz. BIP-32 define el mecanismo del árbol de claves: cada nodo es una clave extendida que contiene una clave junto con un código de cadena de `32-byte`, y cada clave hija se selecciona mediante un índice. El mismo material raíz, las mismas reglas de derivación y la misma ruta reproducen las mismas claves hijas.
Que sea «determinista» hace práctica la copia de seguridad, pero no convierte a todas las carteras en intercambiables. Una frase mnemónica es una forma posible de codificar entropía y producir una semilla, mientras que una ruta de derivación selecciona un nodo y una regla de dirección o script transforma su clave pública en algo que una cadena reconoce. Restaurar solo las palabras puede mostrar una cartera vacía si difieren la frase de contraseña, la ruta, la red, el tipo de script o las reglas de descubrimiento de cuentas.
«Jerárquica» significa que la autoridad puede dividirse en subárboles. Una clave pública extendida a nivel de cuenta puede permitir que un servicio de solo lectura derive claves públicas descendientes normales sin poseer las claves de gasto. Una clave privada extendida puede derivar el subárbol privado correspondiente y debe protegerse como una colección de claves privadas, no como una sola dirección.
Una cartera HD es un diseño de gestión de claves, no un objeto de cartera en la cadena. La blockchain no almacena la frase mnemónica, la semilla, la ruta, las etiquetas ni la copia de seguridad. Son registros fuera de la cadena que mantienen el software de cartera y el usuario.
## Cómo funciona
### 1. De la entropía a la raíz
BIP-39 suele utilizarse antes de BIP-32, pero ambos estándares son distintos. BIP-39 codifica `128-256 bits` de entropía más una suma de comprobación como `12-24 words`, y después aplica PBKDF2-HMAC-SHA512 con `2048` iteraciones a la frase mnemónica normalizada y a la frase de contraseña opcional para producir una semilla de `512-bit`. Cada frase de contraseña produce una semilla válida pero diferente, por lo que una frase ausente o mal escrita no se detecta de forma fiable mediante un mensaje de «contraseña no válida».
BIP-32 usa HMAC-SHA512 con la clave `Bitcoin seed` para convertir los bytes de la semilla en una clave privada maestra y un código de cadena maestro. Esta clave privada extendida raíz es el origen del árbol BIP-32. No todas las carteras deterministas usan BIP-39 o BIP-32, por lo que la recuperación debe identificar el esquema real en vez de deducirlo por la presencia de palabras de recuperación.
### 2. Claves extendidas y derivación de claves hijas
Una clave privada extendida BIP-32 combina una clave privada con un código de cadena; su clave pública extendida neutralizada combina la clave pública correspondiente con el mismo código de cadena. La derivación normal de una clave hija usa la clave pública del nodo padre, el código de cadena y el índice de la hija, por lo que una clave pública extendida puede derivar claves públicas hijas normales. No puede derivar claves privadas hijas.
Las claves hijas reforzadas usan índices desde `2^31` hasta `2^32 - 1` e incorporan material de la clave privada del nodo padre. No pueden derivarse a partir de la clave pública extendida del padre. Las rutas suelen marcarlas con un apóstrofo, como en `m/84'/0'/0'`. El refuerzo limita el daño de un fallo específico de BIP-32: una clave pública extendida padre más una clave privada hija no reforzada correspondiente pueden revelar la clave privada extendida padre.
### 3. Las rutas dan significado al árbol
BIP-44 define `m / purpose' / coin_type' / account' / change / address_index`. Los primeros `3` niveles están reforzados; `change` y `address_index` son normales para que las claves públicas de cuenta puedan generar direcciones de recepción y cambio. Por convención, la rama `0` es externa y la rama `1` es de cambio interno. El descubrimiento de BIP-44 examina el historial de transacciones y usa un límite de separación de `20` direcciones externas consecutivas sin usar.
La ruta es metadato, no un secreto ni una garantía universal. BIP-84 asigna el propósito `84'` a las cuentas SegWit nativas P2WPKH, mientras que otros propósitos o diseños específicos de una cartera producen otros subárboles. El tipo de moneda es una convención de espacio de nombres, no una regla impuesta por una blockchain.
### 4. Las claves no son toda la cartera
Una clave pública todavía necesita reglas de red y de dirección o script. En Bitcoin, la misma clave puede participar en diferentes scripts de salida, y una cartera multifirma también necesita el umbral, las claves de los cosignatarios, el orden de las claves y los orígenes de derivación. Los descriptores de salida BIP-380 vinculan las claves y sus orígenes con expresiones de script explícitas y pueden incluir una suma de comprobación. Por eso, una copia de seguridad compuesta solo por la semilla puede ser insuficiente para recrear lo que la cartera original vigilaba o podía gastar.
Las etiquetas de la cartera, los contactos, las notas de transacciones, las claves importadas, los nombres de las cuentas y algunos ajustes de recuperación de contratos o cuentas inteligentes, por lo general, no se derivan de forma determinista. Requieren una exportación o documentación independiente.
### 5. La copia de seguridad y la recuperación son procesos verificados
Registra la implementación de la cartera, el formato de la frase mnemónica o semilla, si existe una frase de contraseña, la huella maestra, las rutas pertinentes, las redes, los índices de cuenta y los descriptores de Bitcoin o datos de política equivalentes. Mantén los secretos raíz fuera de línea y separados de los metadatos públicos de recuperación cuando sea posible. Un `xpub` no puede gastar por sí solo, pero puede revelar saldos, relaciones entre direcciones y futuros descendientes normales.
Prueba la recuperación en un entorno de confianza antes de depender de la copia de seguridad. Primero compara direcciones o descriptores conocidos sin mover fondos; después verifica tanto las ramas de recepción como las de cambio, las cuentas posteriores, el historial de transacciones y la firma mediante una pequeña transacción controlada. Nunca introduzcas una frase mnemónica, una frase de contraseña o un `xprv` en un sitio web o chat de asistencia que no sea de confianza.
## Ejemplo
Considera una cuenta de Bitcoin SegWit nativa en `m/84'/0'/0'`. El propósito `84'` selecciona la convención BIP-84, `0'` selecciona el espacio de nombres del tipo de moneda Bitcoin y el último `0'` selecciona la primera cuenta. Un sistema de solo lectura puede recibir la clave pública extendida de la cuenta y derivar ramas normales sin recibir la clave privada de la cuenta.
La primera clave de recepción externa está en `m/84'/0'/0'/0/0`; la siguiente, en `m/84'/0'/0'/0/1`. La primera clave de cambio interno está en `m/84'/0'/0'/1/0`. Todas descienden de la misma cuenta, pero la rama y el índice seleccionan claves distintas. Reutilizar la semilla con `m/44'/0'/0'/0/0` selecciona otro subárbol y otra convención de salida; un resultado vacío no demuestra que la semilla sea incorrecta.
Para obtener un registro completo de recuperación de Bitcoin, conserva la copia de seguridad del secreto raíz por separado del descriptor o de los metadatos equivalentes que identifican la huella, la ruta, la clave pública extendida, el tipo de script y la suma de comprobación. Verifica varias direcciones utilizadas anteriormente en ambas ramas. Encontrar solo la primera dirección de recepción demuestra que una hoja es correcta, pero no que se hayan recuperado todas las cuentas, salidas de cambio o políticas de la cartera.
## Riesgos
- **Concentración en una sola raíz:** la vulneración de una semilla raíz o de una clave privada extendida de nivel suficientemente alto puede exponer a todos los descendientes dentro de su alcance.
- **Pérdida de la copia de seguridad:** perder la única copia de seguridad de la semilla, o perder por separado una frase de contraseña BIP-39 no documentada, puede hacer irrecuperables todas las claves derivadas.
- **Falsa confianza en la frase de contraseña:** una frase de contraseña BIP-39 incorrecta crea una cartera válida diferente, que puede parecer una restauración correcta pero vacía.
- **Ruta o script incorrectos:** la semilla correcta con un propósito, cuenta, rama, red o tipo de salida equivocados genera direcciones válidas pero no relacionadas.
- **Copia de seguridad incompleta de la política:** una semilla y una ruta por sí solas pueden no reconstruir las condiciones de gasto multifirma, de descriptor, de una cuenta inteligente o específicas de la cartera.
- **Fuga de privacidad por la clave pública extendida:** un `xpub` puede revelar un grupo de direcciones y permitir el seguimiento continuo de los descendientes normales.
- **Vulneración del padre en BIP-32:** un `xpub` padre junto con una clave privada hija no reforzada correspondiente que se haya filtrado puede revelar el subárbol privado del padre.
- **Herramientas de recuperación no fiables:** sitios web, extensiones, dispositivos falsificados, herramientas del portapapeles o la pantalla compartida pueden capturar todo el secreto raíz.
- **Soportes no probados:** el papel, el metal, los archivos cifrados o las copias de seguridad en hardware pueden fallar por errores de transcripción, corrosión, contraseñas olvidadas o formatos incompatibles.
- **Migración incompleta:** mover las monedas visibles dejando tokens, salidas de cambio, funciones de contratos, aprobaciones o cuentas posteriores bajo la raíz anterior mantiene la exposición.
## Malentendidos comunes
### ¿Una frase de copia de seguridad incluye todos los detalles de la cartera?
No. Puede reproducir el material de clave raíz, pero no necesariamente la frase de contraseña, la convención de derivación, la red, los scripts, la política multifirma, las etiquetas, las claves importadas ni el historial de descubrimiento de cuentas. Conserva los metadatos que necesita la cartera real.
### ¿Es seguro publicar un `xpub` porque no puede gastar?
No. Normalmente no puede firmar, pero puede revelar las direcciones descendientes normales pasadas y futuras y su historial conjunto. En el fallo de BIP-32 descrito anteriormente, combinarlo con una clave privada hija no reforzada correspondiente también puede comprometer el subárbol padre.
### ¿Las direcciones nuevas crean copias de seguridad independientes?
No. Las direcciones nuevas reducen la reutilización de direcciones y mejoran la privacidad, pero los descendientes deterministas siguen controlados por el mismo antepasado. La vulneración de la raíz afecta al subárbol aunque cada pago haya usado una dirección nueva.
### ¿Restaurar una dirección conocida demuestra que la cartera está completa?
No. Valida una combinación de material raíz, ruta y construcción de dirección. La recuperación aún debe abarcar las ramas de recepción y cambio, todas las cuentas usadas, los scripts o políticas y las redes pertinentes.
## Temas relacionados
- [Ruta de derivación de la cartera](/es/crypto/derivation-path/)
- [Frase semilla](/es/crypto/seed-phrase/)
- [Claves públicas y privadas](/es/crypto/public-private-key/)
- [Cartera de hardware](/es/crypto/hardware-wallet/)
- [Cartera fría](/es/crypto/cold-wallet/)
## Fuentes
- [BIP 32: Carteras jerárquicas deterministas](https://bips.dev/32/) - Bitcoin Improvement Proposals (consultado: 2026-08-20)
- [BIP 39: Código mnemónico para generar claves deterministas](https://bips.dev/39/) - Bitcoin Improvement Proposals (consultado: 2026-08-20)
- [BIP 44: Jerarquía multicuenta para carteras deterministas](https://bips.dev/44/) - Bitcoin Improvement Proposals (consultado: 2026-08-20)
- [BIP 84: Esquema de derivación para cuentas P2WPKH](https://bips.dev/84/) - Bitcoin Improvement Proposals (consultado: 2026-08-20)
- [BIP 380: Funcionamiento general de los descriptores de scripts de salida](https://bips.dev/380/) - Bitcoin Improvement Proposals (consultado: 2026-08-20)
Source: https://wiki.fcontext.com/es/crypto/hd-wallet/index.mdx