Descriptores de salida: qué copiar además de las palabras

Tienes las palabras y no encuentras los fondos

Imagina una multifirma 2 de 3. Los tres participantes guardan su seed phrase (en adelante, la seed) en un sitio distinto, y años después se pierde el ordenador donde estaba la billetera (wallet). Dos de ellos recuperan sus palabras, las introducen en un aparato nuevo y en otro programa, y no aparece ni una dirección conocida. Entre los dos tienen las dos firmas que pide el umbral, y aun así no pueden hacer nada.

La razón es que una seed solo produce claves privadas. No dice qué tipo de script se construyó con ellas, por qué ruta se derivaron, qué otras claves participaban ni cuántas firmas hacían falta. El árbol BIP-32 da claves, no estructura. Esa estructura es lo que describe un descriptor.

Qué es un descriptor de salida

El BIP-380 define los descriptores de salida (output descriptors) como un lenguaje sencillo para describir colecciones de scripts de salida. Nacen del problema anterior. Las copias de seguridad consistían solo en claves privadas, hoy casi siempre en forma de mnemónicos BIP-39, y con ellas, dice el BIP, una billetera restaurada no puede saber qué tipos de script y de dirección tiene que producir (BIP-380, traducción propia, consultado el 7 de octubre de 2026). Además, no todas las billeteras usan las mismas rutas de derivación.

La forma general es SCRIPT#CHECKSUM. Un descriptor describe una colección de scripts, no uno solo: con un comodín /* cubre todas las direcciones de una rama.

Cómo se lee: de fuera adentro

Primero un ejemplo de clave única con marcadores genéricos, sin aspecto de clave real y sin checksum:

wpkh([HUELLA/84h/0h/0h]XPUB_CUENTA/<0;1>/*)

Se lee así. wpkh es el tipo de script (SegWit nativo de clave única; ver tipos de direcciones). Entre corchetes va el origen: la huella (fingerprint) de la clave maestra, que son los primeros 32 bits de su identificador según BIP-32, y la ruta hasta la cuenta (ver rutas de derivación). Después, la xpub de esa cuenta, la rama <0;1> (0 para recibir, 1 para el cambio) y *, el índice de cada dirección.

La huella sirve para saber de qué seed viene cada clave. Una hardware wallet la compara con la suya antes de firmar. Son exactamente 8 caracteres hexadecimales.

Un ejemplo completo sale de la frase pública de prueba de BIP-39, «abandon … about». Esa frase está comprometida: nunca guardes fondos en ella.

wpkh([73c5da0a/84'/0'/0']xpub6CatWdiZiodmUeTDp8LT5or8nmbKNcuyvz7WyksVFkKB4RHwCD3XyuvPEbvqAQY3rAPshWcMLoP2fMFMKHPJ4ZeZXYVUhLv1VMrjPC7PW6V/<0;1>/*)#hpg6d6w2

Su primera dirección de recepción es bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu. Puedes pegarlo en el inspector de descriptores y ver cómo se separa cada parte.

Tres detalles de sintaxis. El marcador de endurecido puede ser h o ', pero la H mayúscula es inválida. Una ruta tampoco puede acabar en barra (…/0/). Y la tupla <0;1> es multipath, varias rutas en una (BIP-389, todavía Draft en octubre de 2026): una sola tupla por clave, y si varias claves la llevan, todas con la misma longitud.

Bitcoin Core acepta multipath desde la 29.0 (14 de abril de 2025), que es la primera versión con la PR #22838, su implementación de referencia. Con una versión anterior, o con una billetera que no la entienda, hay que partir el descriptor en dos, uno con /0/* para recibir y otro con /1/* para el cambio. Y aunque Core acepta el descriptor multipath al importar, lo guarda partido en dos, y listdescriptors te devuelve dos descriptores, cada uno con su checksum (así sigue en la 31.1, octubre de 2026). Guarda los dos: el que lleva /1/* en sus claves es el del cambio.

Una multifirma completa

Aquí está lo que la seed no contiene. Una 2 de 3 en P2WSH, con marcadores genéricos y la ruta que el BIP-48 propone para este caso:

wsh(sortedmulti(2,[HUELLA_A/48h/0h/0h/2h]XPUB_A/<0;1>/*,[HUELLA_B/48h/0h/0h/2h]XPUB_B/<0;1>/*,[HUELLA_C/48h/0h/0h/2h]XPUB_C/<0;1>/*))

De fuera adentro: el script (wsh), la política (sortedmulti(2,…), umbral 2) y tres claves con su origen. La seed de A contiene la clave de A, pero no XPUB_B ni XPUB_C. Dos seeds no bastan. El script lleva las tres claves públicas, también la de quien no va a firmar, y la de C no sale de las seeds de A ni de B. Sin ella no se puede calcular ni una dirección. El BIP-388 lo dice claro: en estos casos la seed sola ya no basta para encontrar las billeteras con fondos, y perder la copia del descriptor probablemente lleve a perder los fondos para siempre (traducción propia).

La diferencia entre multi y sortedmulti también cuenta. Con multi el orden de las claves es parte del script: con A, B, C y con B, A, C salen direcciones distintas. sortedmulti ordena las claves ya derivadas y fija el resultado. Las claves derivadas avanzan juntas: la dirección de índice 5 usa la clave de índice 5 de cada xpub. Y una lista de xpub no dice ni el umbral, ni el tipo de script, ni si el orden importa. Por eso hay que guardar el descriptor entero.

El BIP-383 pone límites a multi: k no puede superar n, como mucho 3 claves arriba del todo, 15 claves comprimidas dentro de sh() por el límite de 520 bytes (7 si están sin comprimir), y 20 en los demás casos. En Taproot se usan multi_a y sortedmulti_a (BIP-387), que solo van dentro de tr(). Para scripts con timelocks o con árboles Taproot (ver Taproot y timelocks), el descriptor (o su forma compacta, BIP-388) es la forma estándar de describir la política completa. Miniscript es el lenguaje que permite escribir esas políticas dentro de un descriptor.

El checksum: qué protege y qué no

Los ocho caracteres tras # son un código de detección de errores parecido al de bech32 (BCH), escrito con su mismo alfabeto. El BIP no cuenta caracteres, cuenta «símbolos». Cambiar un carácter por otro de esta lista de 32, 0123456789()[],'/*abcdefgh@:$%{}, cuenta como un error de un símbolo, y una mayúscula por una minúscula, también. Cualquier otro cambio de un carácter cuenta como uno o dos. La xpub usa caracteres de fuera de la lista, pero trae su propio checksum de Base58Check.

Con eso, el BIP-380 garantiza detectar cualquier error de 1 símbolo, cualquier error de 2 o 3 símbolos en descriptores de hasta 49154 caracteres, y cualquier error de 4 símbolos hasta 507 caracteres. Para errores aleatorios, la probabilidad de que pasen sin detectar es de 1 entre 2⁴⁰ (BIP-380, consultado el 7 de octubre de 2026). Cuatro erratas no son siempre cuatro símbolos, así que no conviertas esas cifras en «detecta hasta cuatro erratas».

Es una defensa contra errores de copia. Bitcoin Core no te dice qué carácter falló ni lo corrige. Te dice qué checksum saldría con lo que has pegado. No lo copies encima del tuyo: si no coinciden, la errata está en el texto. Tampoco confirma que el descriptor sea el tuyo: uno ajeno con su checksum correcto pasa igual. Core lo incluye en todas sus salidas y lo exige en órdenes como importdescriptors y deriveaddresses; getdescriptorinfo lo calcula si falta. El BIP-380 deja el checksum como opcional, y cada programa decide si acepta un descriptor sin él.

Un detalle que sorprende: el checksum depende de cada carácter, así que cambiar el marcador de endurecido lo cambia. Con h en lugar de ', el ejemplo de arriba pasa de #hpg6d6w2 a #qf45pmyh. Desde la 26.0 (6 de diciembre de 2023), Bitcoin Core muestra h en listdescriptors y órdenes parecidas, salvo con el parámetro private, que respeta el marcador con el que se creó o importó el descriptor. Dos copias del mismo descriptor con marcadores distintos son equivalentes, pero no comparten checksum. Si ves un descriptor escrito con una y otro, no lo tomes por alterado: comprueba cada copia con su propio checksum.

Qué copiar además de las palabras

Siempre, la seed y, si la hay, la passphrase, guardadas por separado (ver passphrase y estrategias de copia de la seed). A partir de ahí depende de la billetera:

• Clave única estándar: el descriptor, o al menos el tipo de script, la cuenta y la huella. Si usaste rutas estándar, un programa que pruebe las habituales suele encontrar los fondos, pero el descriptor evita adivinar. Si hay passphrase, el descriptor y la huella van con la passphrase, no con las palabras.
• Multifirma: con cada juego de claves, el descriptor completo: todas las xpub, sus orígenes, el umbral y si es multi o sortedmulti. Si cada participante guarda solo su seed y se pierde el ordenador con la billetera, basta con que falte una sola clave para dejar los fondos inaccesibles, aunque el umbral prometía aguantarlo.
• Timelocks, Miniscript o Taproot con árbol: el descriptor completo es imprescindible.
• Útil: la fecha o altura de creación, para acelerar el reescaneo, y el nombre del software que lo generó.

Para la herencia, esto se vuelve decisivo: unos herederos con las palabras y sin el descriptor de una multifirma pueden no llegar a gastar nada (ver herencia de bitcoin).

Cuánto de secreto es un descriptor

Depende de lo que lleve dentro. Un descriptor con xpub no permite gastar, pero revela todo el historial de esa cuenta, igual que una xpub suelta. No lo pegues en servicios de terceros ni en un chat, y guárdalo con cuidado aunque no mueva fondos. En un 2 de 3, quien tenga el descriptor y una seed sigue sin poder gastar: le falta otra clave, igual que si no tuviera el descriptor. Lo que gana es ver el saldo y todo el historial, y saber qué huellas tienen las otras dos claves. Por eso, si guardas una copia del descriptor junto a cada seed, que es lo normal, ese sitio se protege como lo que es: el sitio de una seed. Si esa clave lleva passphrase, la copia va con la passphrase y no con las palabras, porque le diría a quien las robe si ha acertado la passphrase. En cambio, un descriptor con claves privadas (xprv o WIF), como el que puede exportar una orden como listdescriptors true, es tan secreto como la seed: quien lo tenga controla los fondos.

Por eso el inspector de descriptores está pensado solo para descriptores públicos y avisa si detecta una clave privada. Esa precaución vale fuera de la herramienta: nunca pegues un descriptor con claves privadas reales en una web ni en un programa que no controles. Los vectores públicos de los BIP incluyen claves privadas de prueba, que están comprometidas: nunca guardes fondos con ellas.

Qué billeteras los usan hoy

Bitcoin Core los incorporó en órdenes RPC en la 0.17.0 (doc/bips.md de Core). Desde la 23.0 (25 de abril de 2022) las billeteras de descriptores son el tipo por defecto, y desde la 30.0 (10 de octubre de 2025) las billeteras legacy con Berkeley DB ya no se pueden crear ni cargar, solo migrar con la orden migratewallet (notas de versión de Core).

Algunos dispositivos de firma (Ledger, BitBox02 y Jade, según el propio BIP) usan el BIP-388, wallet policies: una forma compacta de descriptor pensada para hardware wallets, en estado Complete a octubre de 2026. Otros registran el descriptor con su propio formato. Y el soporte de musig(), en el BIP-390 aún Draft, llegó a Core en dos pasos: análisis del descriptor desde la 30.0 y firma desde la 31.0. Qué billeteras exportan el descriptor con checksum o con h en lugar de ' varía según el programa. Comprueba lo que produce el tuyo (ver hardware wallets y firma sin conexión, donde, en multifirma, el descriptor se registra una vez en el aparato y cada PSBT lleva las rutas de sus claves).

Qué significa esto para ti

Si usas una billetera de clave única, exporta y guarda el descriptor junto a la seed; si lleva passphrase, junto a la passphrase, porque su huella le diría a quien robe las palabras si ha acertado la passphrase. Cuesta una línea y ahorra dudas. Si usas multifirma, trátalo como parte obligatoria de cada copia, no como un extra. Guarda varias copias del descriptor completo en sitios distintos y verifica el checksum al restaurar.

Al montar una multifirma, cada participante registra el descriptor en su aparato y comprueba en la pantalla de registro el umbral y las tres xpub, una a una. Cada xpub se compara con la que mostró su propio aparato al exportarla, o con una copia hecha a partir de esa pantalla, nunca con un fichero del mismo ordenador (los detalles, en firma sin conexión). Después, todos comparan la primera dirección. Así se detecta un descriptor cambiado antes de meter fondos, cosa que el checksum no ve.

Luego haz un simulacro de recuperación, antes de meter los fondos de verdad y con una cantidad pequeña. Prueba las copias una a una: restaura cada seed que viva en una hardware wallet en otra de repuesto vacía (nunca la teclees en un ordenador ni en un móvil). Si una clave nació en una app, no la metas en ninguna hardware wallet: pruébala antes de mandar nada a la multifirma, ni siquiera la cantidad pequeña, con la comprobación de copia de la app o borrándola y restaurándola en esa misma app del mismo aparato con el teclado del sistema, solo si ninguna billetera de esa seed tiene fondos, tampoco con passphrase (ver estrategias de copia de la seed). Prueba también el descriptor en el programa coordinador (el del ordenador, como Sparrow o Bitcoin Core, que junta las xpub y prepara las transacciones). Hazlo a partir de las copias guardadas y no de la billetera que ya funciona: lo que se prueba es la copia. No borres ningún aparato de la multifirma para probar su copia, y menos varios a la vez: en ningún momento puede haber menos claves disponibles que las que pide el umbral. Al terminar cada prueba, borra el aparato de repuesto, porque con la seed dentro es una copia más de esa clave. Los pasos están en estrategias de copia de la seed. Recuperar tras un robo es otro caso. Si te roban o pierdes el aparato de una clave, esa clave queda expuesta: solo se restaura si hace falta para llegar al umbral y mover los fondos, y entonces en un aparato limpio, nunca en una hardware wallet (ver recuperar una billetera).

Piensa en cómo encajan estas copias con tu modelo de amenazas: el descriptor es menos sensible que la seed, pero no es público.