HD Wallet

Alice abre la pantalla para recibir y la cartera le muestra una dirección. Recibe en ella 10 000 satoshis, las pequeñas unidades del bitcoin. Para el siguiente pago, la aplicación ofrece otra dirección, que recibe 20 000 satoshis. Si esos son sus únicos ingresos sin gastar, la cartera muestra un total de 30 000 satoshis. La nueva dirección no ha creado una cuenta independiente ni ha trasladado automáticamente el dinero anterior. La aplicación gestiona las claves de ambos ingresos. Una HD Wallet facilita este funcionamiento. HD significa Hierarchical Deterministic: jerárquica porque las claves forman una estructura de ramas, y determinista porque la misma semilla y la misma ruta producen las mismas claves, también al recuperar la cartera. La ruta es una secuencia de números que indica qué rama y qué clave debe calcular el programa. Alice normalmente no tiene que ocuparse de ella para recibir, pero la recuperación necesita las rutas correctas. Una copia del secreto inicial puede cubrir también las direcciones futuras; aun así, hay que conservar la configuración de la cartera. Usar direcciones nuevas evita reutilizarlas, pero por sí solo no garantiza el anonimato. [1] [12]

Una clave pública extendida, normalmente llamada xpub, permite calcular claves públicas de una parte de esta estructura. No contiene las claves privadas necesarias para firmar pagos. Por eso un xpub por sí solo no permite gastar; para crear direcciones concretas, la aplicación también necesita conocer su formato. Una cartera watch-only con el xpub adecuado puede crear direcciones y observar pagos sin claves de firma. Sin embargo, filtrar ese xpub puede vincular direcciones pasadas y futuras de la rama, saldos y transacciones. Comparta solo la rama necesaria. Ni siquiera un xpub correcto impide que un ordenador comprometido muestre una dirección ajena. Verifique la dirección de recepción en un dispositivo de firma fiable que conozca la cartera. [1] [12] [14]

Una tienda puede crear una dirección distinta para cada pedido. La web necesita conocerlas, pero no debería tener las claves para gastar lo recaudado. BIP32 permite separar esa rama de recepción del resto de la cartera. Pieter Wuille redactó la propuesta, asignada el 11 de febrero de 2012. Es un estándar de carteras, no una regla de consenso. Las palabras de respaldo BIP39, los tipos de script y el procedimiento completo de recuperación pertenecen a otras capas. [1] [11] [12]

BIP32 añade a la clave un chain code de 256 bits: 32 bytes para las derivaciones siguientes. La forma privada contiene un escalar k de secp256k1 y el chain code c; la pública utiliza K = point(k) y el mismo c. La clave maestra se genera con HMAC-SHA512, usando la cadena exacta «Bitcoin seed» como clave de la función y la semilla como datos. Los primeros 32 bytes son el candidato a clave privada; los últimos 32, el chain code. El cero o un valor igual o superior al orden n de la curva invalidan la clave maestra. [1]

Derivar es calcular, no buscar en una lista guardada. Hay dos formas de derivación: normal y hardened. La normal permite calcular nuevas claves públicas a partir de la clave pública extendida del padre; un paso hardened requiere la clave privada extendida del padre. CKDpriv calcula I = HMAC-SHA512(cpar, data), lo divide en IL e IR y suma parse256(IL) a la clave privada del nodo padre módulo n. IR es el nuevo chain code. La derivación normal utiliza serP(Kpar) || ser32(i); la hardened, 0x00 || ser256(kpar) || ser32(i), con i ≥ 2^31. CKDpub solo genera ramas públicas normales, sumando point(parse256(IL)) a Kpar. Cambiar el número de rama cambia las claves posteriores. [1]

Un xpub permite derivar claves públicas mientras la ruta no cruce un paso hardened. Hay una contrapartida importante: el xpub del padre junto con una clave privada filtrada de un hijo normal permite calcular la clave privada del padre. También quedan expuestas sus otras ramas. Hardened bloquea ese cálculo inverso, pero no protege frente al robo de la semilla, una fuente de aleatoriedad débil o la aprobación de una transacción maliciosa. [1]

En mainnet, la codificación pública estándar empieza por xpub y la privada por xprv; sus versiones son 0x0488B21E y 0x0488ADE4. Antes de Base58Check, el registro tiene 78 bytes: versión 4, profundidad 1, huella del padre 4, número del hijo 4, chain code 32 y datos de clave 33. El resultado tiene 111 caracteres. La huella corta ayuda a relacionar claves, pero no prueba una identidad. Los prefijos ypub/zpub de SLIP132 a veces indican el tipo de script; cambiar el prefijo no cambia por sí solo las claves ni las reglas de la cartera. [1] [9]

BIP43 reservó el primer nivel hardened para el propósito. BIP44 utiliza m / 44' / coin_type' / account' / change / address_index. Tras la cuenta viene la rama 0 de recepción o la 1 de cambio, seguida del número de dirección. El apóstrofo o h indica un índice aumentado en 2^31. La búsqueda BIP44 aplica un gap limit de 20: se detiene tras 20 direcciones de recepción consecutivas sin usar. BIP48 describe Multisig; BIP84, el propósito 84' para SegWit nativo; y BIP86, el 86' para Taproot de una sola clave. Son convenciones que no están guardadas en la semilla ni las imponen los nodos. [2] [3] [4] [5] [6]

Las claves no determinan por sí solas el script que protege las monedas. Un Output Descriptor puede registrar el origen y las rutas de las claves, una construcción como wpkh(), las firmas requeridas, otros participantes de Multisig y una suma de comprobación. Un descriptor multipath puede reunir las ramas de recepción y cambio. La semilla de un participante no reconstruye los demás xpub ni las reglas compartidas. Respalde también un descriptor público verificado o una exportación de configuración y proteja su privacidad. Si contiene claves privadas, trátela como un secreto. [7] [8] [10] [13]

La semilla permite derivar de nuevo las claves, pero la aplicación necesita su formato, la BIP39 passphrase si se usó, la red, el tipo de script, coin type, las cuentas, ambas ramas y el alcance de búsqueda. Multisig necesita además la configuración compartida. Un saldo cero no demuestra que las monedas se hayan perdido: quizá se está buscando en otra ruta. Una prueba segura en un dispositivo fiable debe encontrar los UTXO correctos, es decir, las salidas de transacciones que siguen sin gastarse, y comprobar la firma. Nunca introduzca una semilla real ni palabras de respaldo en una herramienta web o un ordenador corriente conectado. [3] [7] [10] [11]

BIP32 contempla resultados inválidos poco frecuentes: parse256(IL) ≥ n, una clave privada derivada igual a cero o un punto público en el infinito. En esos casos se prueba el siguiente índice. Es más habitual que falten la ruta, la rama de cambio o un tipo de script compatible. Antes de cambiar de aplicación, compruebe que encuentra las monedas y haga una transferencia pequeña de prueba. Conserve el respaldo y la configuración originales hasta verificar el nuevo procedimiento. El xprv proporciona las claves necesarias para firmar, el xpub revela relaciones financieras y el descriptor indica cómo construir la cartera. [1] [7] [9] [10]