Saltar al contenido
Financial Context Wiki

Rutas de derivación de carteras: estándares, descubrimiento y recuperación

Aprende cómo las rutas de derivación de monederos seleccionan claves secundarias deterministas, cómo difieren los niveles endurecidos y las convenciones de cuenta, y cómo verificar las rutas durante la recuperación.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Una ruta de derivación de billetera es una secuencia ordenada de índices de hijos que indica a un algoritmo determinista de derivación de claves qué nodo seleccionar de un árbol de claves. En la notación común BIP-32, m/84'/0'/0'/0/7 comienza en el nodo privado maestro m y recorre cinco hijos. El apóstrofe marca un hijo endurecido BIP-32. Una ruta es metadatos de enrutamiento: no es una clave privada, no cifra una semilla, no identifica por sí misma un saldo de blockchain, y no puede recuperar nada sin el material raíz correcto y el algoritmo de derivación.

Para las carteras estilo BIP-44, la plantilla es m / purpose' / coin_type' / account' / change / address_index. Los niveles tienen significados acordados, no etiquetas arbitrarias. purpose selecciona una convención de cartera, coin_type separa los espacios de nombres de activos registrados, account separa cuentas lógicas, change normalmente distingue direcciones externas de recepción (0) de direcciones internas de cambio (1), y address_index selecciona una hoja. BIP-44 fortalece los primeros tres niveles y deja los dos últimos sin fortalecer para que una clave pública extendida de cuenta pueda derivar direcciones de recepción y cambio sin tener claves privadas.

La misma mnemotecnia puede conducir a muchos conjuntos de direcciones válidas pero no relacionadas. Para Bitcoin, las rutas de una sola clave comunes incluyen m/44'/0'/account'/change/index para P2PKH, m/49'/0'/account'/change/index para P2WPKH anidado en P2SH, m/84'/0'/account'/change/index para P2WPKH SegWit nativo, y m/86'/0'/account'/change/index para Taproot P2TR de una sola clave. Una billetera también debe conocer la construcción de la salida o del script; una ruta por sí sola no es una política completa de billetera Bitcoin.

Otros ecosistemas reutilizan partes de esta notación sin garantizar semánticas idénticas. Ether está registrado como tipo de moneda BIP-44 60, y m/44'/60'/0'/0/index es una convención común de cuentas de propiedad externa, pero las implementaciones de billeteras han utilizado múltiples diseños de cuentas. La misma clave EVM puede producir la misma dirección de cuenta en varias redes EVM, aunque los saldos y los historiales de transacciones son específicos de cada cadena. Las claves BLS de validadores Ethereum utilizan ERC-2333 y ERC-2334 en lugar de BIP-32; su ruta m/12381/3600/account/use no tiene apóstrofes y no es interoperable con un árbol BIP-32. Por lo tanto, la recuperación requiere la implementación exacta, la curva, la semilla o frase de paso, la convención de ruta, la red y la construcción de dirección, no una cadena que parezca plausible.

Cómo identificar y verificar una ruta de derivación

1. Determinar el material raíz y el algoritmo de derivación

Inventariar el formato mnemónico, la lista de palabras, la frase de paso opcional, la semilla en bruto o la clave extendida, y la implementación de software o hardware que creó la billetera. BIP-39 convierte 128 en 256 bits de entropía en un mnemónico y deriva una semilla 512-bit a partir de ese mnemónico más la frase de paso exacta; cada frase de paso produce una semilla sintácticamente válida pero diferente. BIP-32 luego deriva claves extendidas secp256k1 a partir de una semilla. Otras familias de billeteras pueden usar diferentes esquemas mnemónicos, curvas, funciones de derivación de claves o reglas de clave maestra, por lo que la coincidencia de palabras no prueba una raíz coincidente.

2. Identificar el estándar, la red y la función de la clave

Determine si el objetivo es una clave de pago Bitcoin, una cuenta de propiedad externa EVM, una clave de validador, un firmante multifirma, un administrador de contrato u otra autoridad. Registre la cadena y la red, el estándar y la versión aplicables, la curva de la clave, el tipo de salida o dirección y la aplicación de la billetera. Un registro de tipo de moneda SLIP-0044 asigna un espacio de nombres; no prueba que cada billetera para ese activo siga BIP-44, respalde un proyecto o impida que otra cadena derive la misma clave en otro lugar.

3. Interpretar exactamente cada componente de la ruta

Trate / como un límite padre-hijo y conserve cada índice, profundidad y marcador de endurecimiento. Bajo BIP-32, los hijos normales usan los índices 0 hasta 2^31 - 1; los hijos endurecidos usan 2^31 hasta 2^32 - 1, comúnmente escritos con ', h o H. Por lo tanto, 7' codifica el número de hijo 2^31 + 7, no el hijo ordinario 7. Confirme cómo una interfaz de importación representa la raíz, si acepta una ruta completa o un sufijo relativo, y si una clave extendida exportada ya se encuentra bajo parte de esa ruta.

4. Vincular la ruta con la semántica de la dirección o salida

Para las billeteras de la familia BIP-44 Bitcoin, confirme los purpose, coin_type, account, change y address_index, luego confirme de manera independiente el tipo de script y la red previstos. BIP-49, BIP-84 y BIP-86 utilizan deliberadamente valores de propósito diferentes para que los tipos de salida incompatibles no aparezcan silenciosamente en una cuenta. Para billeteras multisig o de descriptor, preserve cada origen de clave, huella digital del maestro, sufijo de derivación, umbral, orden de claves, construcción del script y suma de verificación; un solo camino no puede reconstruir la política completa.

5. Reproducir el descubrimiento de cuentas y direcciones

No infiera pérdida de una cuenta predeterminada vacía. La exploración de descubrimiento BIP-44 verifica las cuentas en orden y escanea la cadena externa, usando un límite de distancia de direcciones de 20 direcciones consecutivas no usadas. Las billeteras que crearon direcciones más allá de ese límite, usaron ramas internas de manera inusual, omitieron cuentas o aplicaron un diseño propietario pueden no ser encontradas por un escaneo predeterminado. Busque solo con datos confiables de solo consulta o derivación fuera de línea, establezca límites explícitos, documente cada rama explorada y evite subir una mnemónica o clave privada extendida a un sitio web.

6. Verificar la identidad de la cartera antes de confiar en el saldo

Compare la huella digital maestra, la clave pública extendida a nivel de cuenta cuando sea apropiado, la ruta de origen completa y varias direcciones de recepción y cambio registradas previamente. Para Bitcoin, derive los scripts de salida esperados o descriptor y consulte la red correcta para el historial de transacciones, incluidos los outputs gastados. Para cadenas basadas en cuentas, verifique el chainId exacto, la dirección, los contratos de tokens y la actividad histórica. Un saldo vacío es una evidencia débil: la dirección puede ser incorrecta, la red o el índice pueden diferir, o los activos ya pueden haberse movido.

7. Recuperar o migrar mediante un flujo controlado

Use software verificado y compatible en un entorno confiable; prefiera importar un descriptor solo de observación o la clave pública de la cuenta para el descubrimiento antes de exponer material de firma. Pruebe la firma y recuperación con una cuenta aislada o una transacción pequeña, luego reconcilie las direcciones derivadas, el historial en cadena, la propiedad de las salidas, las tarifas y el estado final. Si los secretos se ingresaron en una herramienta de recuperación no confiable, trátelos como comprometidos y migre todos los activos, roles de contrato, aprobaciones, deberes de validador y autoridades de recuperación a una raíz nueva en lugar de continuar usando la billetera recuperada.

Ejemplos calculados

Interpretación de una ruta Bitcoin con derivación endurecida

Considere m/84'/0'/2'/1/17. Sus campos son el propósito SegWit nativo 84', el tipo de moneda Bitcoin 0', la cuenta 2', la rama interna o de cambio 1 y el índice de dirección 17. Como los índices endurecidos BIP-32 suman 2^31 = 2,147,483,648, sus números de hijo serializados son 84' = 2,147,483,732, 0' = 2,147,483,648 y 2' = 2,147,483,650. Los dos últimos siguen siendo los índices normales 1 y 17; omitir un apóstrofo selecciona otro subárbol, no una grafía equivalente.

Una brecha de direcciones que oculta una dirección usada

Suponga que la rama externa usó direcciones en los índices 0 y 5, y después la cartera escanea de 6 a 25 y encuentra 20 direcciones consecutivas sin uso. Con la regla de brecha de BIP-44, el descubrimiento se detiene en 25, por lo que la dirección usada en 26 queda después de la condición de parada y se omite. Ampliar el escaneo hasta un límite explícito y documentado puede hallarla, pero la causa es que la cartera de origen creó una dirección más allá de la brecha estándar sin actividad intermedia.

Cómputo de una búsqueda de recuperación acotada

Un registro de recuperación no precisa cuál de las 4 familias de propósito Bitcoin (44', 49', 84' y 86') se usó, ni cuál de 3 cuentas, 2 ramas y los primeros 20 índices. La búsqueda inicial tiene 4 × 3 × 2 × 20 = 480 hojas candidatas. Hallar una dirección conocida identifica una ruta candidata, no necesariamente toda la cartera: aún deben revisarse el cambio, los índices posteriores, otras cuentas, el descriptor y el historial. Explicitar las dimensiones hace reproducible la recuperación y evita tanteos sin límite.

Por qué una xpub de cuenta no es un dato público ordinario

Para un hijo BIP-32 no endurecido, los escalares privados cumplen child = parent + tweak (mod n). En un ejemplo simplificado módulo 101, si los datos de derivación expuestos por la clave pública extendida de cuenta fijan tweak = 37 y se filtra el escalar privado hijo 12, entonces parent = 12 - 37 mod 101 = 76. BIP-32 real usa el orden del grupo secp256k1 y valores derivados con HMAC, pero la consecuencia algebraica es igual: una xpub padre más una clave privada descendiente no endurecida correspondiente puede revelar la clave privada extendida padre y su subárbol. Las fronteras de cuenta endurecidas limitan este fallo.

Riesgos y fallos de revisión

  • Mnemónico o frase de paso incorrectos: una sola palabra, su orden, la normalización Unicode o una frase de paso distinta produce otra raíz que puede parecer válida.
  • Esquema de derivación incorrecto: aplicar BIP-32 a una cartera que utilizó otro esquema mnemónico, curva, KDF o algoritmo de clave maestra deriva claves no relacionadas.
  • Red o tipo de moneda incorrectos: una raíz correcta en otro espacio de nombres puede generar direcciones plausibles mientras la cadena prevista sigue sin explorarse.
  • Propósito o script incorrectos: confundir 44', 49', 84' o 86' puede omitir la clase de salida Bitcoin que realmente contiene fondos.
  • Marcador de endurecimiento ausente: 7, 7', 7h y 7H pueden interpretarse de otra forma o rechazarse; las claves hijas endurecidas y normales no son intercambiables.
  • Índice de cuenta incorrecto: revisar únicamente la cuenta 0' puede omitir fondos o facultades de cuentas lógicas posteriores.
  • Confusión entre rama externa y de cambio: escanear solo la rama 0 puede omitir salidas de cambio de la rama 1 o una estructura propia de la cartera.
  • Índice de dirección incorrecto: reconocer la primera dirección no demuestra que se hayan cubierto índices posteriores, omitidos o direcciones importadas.
  • Fallo por brecha de direcciones: 20 direcciones externas consecutivas sin uso pueden detener el escaneo BIP-44 antes de un uso posterior no conforme.
  • Fallo por cuenta omitida: el descubrimiento secuencial puede detenerse en una cuenta sin uso y no llegar a otra creada después.
  • Política Bitcoin incompleta: sin descriptor, scripts, umbral, orden de claves, huellas o suma de comprobación, una ruta puede no reconstruir las salidas financiadas.
  • Convención propia de la cartera: una aplicación puede usar estructuras antiguas, propietarias o de migración que una herramienta genérica no enumera.
  • Fuga de privacidad de la clave pública extendida: una xpub puede revelar grupos de direcciones, historial, saldos y futuros descendientes no endurecidos.
  • Exposición excesiva de la clave privada extendida: importar una xprv puede exponer un subárbol completo, no solo la hoja necesaria para una operación.
  • Compromiso de la clave padre BIP-32: una xpub padre junto con una clave privada hija no endurecida correspondiente puede revelar la clave privada extendida padre y su subárbol.
  • Falsa confianza en el formato de dirección: una dirección sintácticamente válida no acredita la semilla, ruta, red, script ni titularidad previstas.
  • Confusión entre cadenas con la misma dirección: una clave EVM puede producir la misma dirección en varias redes, aunque saldos, nonce, tokens y riesgos sean distintos.
  • Software de recuperación malicioso: un sitio web, extensión, herramienta de pantalla compartida, monitor del portapapeles, registrador o dispositivo falso puede capturar el secreto raíz.
  • Confusión entre importar y barrer: importar mantiene vigente la autoridad antigua; barrer o migrar crea una transacción y exige revisar comisión y destino.
  • Recuperación incompleta: hallar un saldo sin verificar firmas, cambio, contratos de tokens, roles, aprobaciones, claves de validadores y copias puede dejar activos ocultos o expuestos.

Errores comunes

¿La ruta de derivación es una contraseña o un secreto?

No. Un camino normalmente describe la estructura pública y debe conservarse como metadatos de recuperación. No reemplaza la mnemotecnia, frase de paso, semilla, clave privada o política de la billetera. Publicar un camino puede revelar información organizacional, pero la posesión del camino por sí sola no confiere autoridad de firma.

¿El mismo mnemónico siempre restaura automáticamente la misma cartera?

No. El resultado también depende del esquema mnemónico, la contraseña exacta, el procesamiento de la semilla, el algoritmo de derivación, la ruta, la curva, la red y la construcción de la dirección o script. El software de la cartera puede elegir diferentes valores predeterminados incluso cuando acepta las mismas palabras.

¿El tipo de moneda impide usar una clave en otra cadena?

No. El tipo de moneda es un espacio de nombres de derivación y una convención de compatibilidad, no un permiso de protocolo. El software puede derivar o reutilizar una clave en otro lugar, y las redes EVM comúnmente exponen la misma dirección de cuenta para la misma clave privada.

¿Una cuenta recuperada sin saldo demuestra que los activos desaparecieron?

No. Solo demuestra que las direcciones y la red consultadas actualmente no muestran saldo detectado. Caminos incorrectos, cuentas, sucursales, tipos de script, límites de descubrimiento, indexación de tokens o selección de red pueden ocultar toda la historia prevista.

¿Puede una herramienta de recuperación probar de forma segura todas las rutas posibles?

No. El espacio de búsqueda puede ser grande, las convenciones de billetera no son totalmente universales, y exponer un secreto raíz a una herramienta no confiable es en sí mismo un evento de pérdida. Use la procedencia, huellas digitales registradas y direcciones, descubrimiento fuera de línea limitado y software verificado para reducir la búsqueda.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...