La respuesta corta
Un descriptor de salida de Bitcoin es una receta compacta para los scripts que una wallet debe reconocer. Dice cómo se derivan las claves, qué clase de dirección crean y, a veces, qué ramas son para recibir y cuáles para el cambio.
Eso cubre un hueco que una frase seed no puede cubrir por sí sola. Las mismas claves pueden envolverse en condiciones de gasto diferentes, así que restaurar solo las claves no siempre le dice al nuevo software de wallet qué debe buscar.
Cómo funciona en realidad
Bitcoin no le paga a una cuenta con nombre. Cada salida lleva un script que declara la condición para gastarla. Una wallet encuentra su dinero generando los scripts que espera y comparándolos con las salidas de la cadena. Si genera el tipo equivocado de script, las claves pueden ser correctas mientras el saldo parece cero.
BIP 380 define el lenguaje general de descriptores. Su motivación es directa: los respaldos de claves privadas se volvieron insuficientes cuando las wallets empezaron a usar varios tipos de salida y varias rutas de derivación. Un descriptor anota esas decisiones en lugar de pedirle a la wallet restaurada que adivine.
Este ejemplo abreviado describe una familia de salidas SegWit nativas:
wpkh([d34db33f/84h/0h/0h]xpub.../0/*)#checksum
Se lee de afuera hacia adentro:
wpkh(...)indica que se construyan salidas pay-to-witness-public-key-hash, la forma que suele mostrarse como una direcciónbc1q.[d34db33f/84h/0h/0h]registra una huella de clave y la ruta endurecida desde el origen de esa clave. Es procedencia para la clave, no un secreto.xpub.../0/*identifica una clave pública extendida, la rama de recepción y un comodín para cada índice hijo de esa rama.#checksumdetecta errores al copiar la cadena del descriptor. BIP 380 especifica un checksum de ocho caracteres y garantiza detectar cualquier error de un símbolo.
El descriptor es una receta para una colección, no para una sola dirección. Reemplazar el comodín por 0, 1 o 2 produce claves hijas distintas y, por lo tanto, scripts distintos. La documentación de descriptores de Bitcoin Core también admite formas multipath que reúnen las ramas de recepción y cambio en una expresión. La diferencia importa porque el cambio no debe presentarse como un pago nuevo de otra persona.
Las funciones externas llevan la política. wpkh(KEY) describe una salida SegWit nativa
de una sola clave. tr(KEY) describe una salida Taproot.
wsh(sortedmulti(2,KEY,KEY,KEY)) puede describir una política multifirma de dos de tres
cuyas claves públicas se ordenan antes de construir el script. Las claves solas no pueden
decirle a la wallet restaurada cuál de esas políticas era la pretendida.
Bitcoin Core expone el mismo modelo mediante sus comandos de wallet y utilidades.
getdescriptorinfo
devuelve una forma pública canónica, un checksum e indicadores que muestran si la expresión
tiene rango, si se puede resolver o si contiene claves privadas. Ese último indicador es la
línea entre una descripción que solo puede observar y otra que quizá pueda gastar.
Por qué importa
El primer beneficio es una wallet de solo lectura mejor. Un descriptor que contiene claves públicas extendidas puede generar los mismos scripts que la wallet firmante sin llevar las claves privadas. Así, un nodo puede encontrar pagos entrantes y construir transacciones sin firmar mientras un dispositivo sin conexión conserva el poder de firmar. Es útil, pero el descriptor sigue siendo sensible: una clave pública extendida puede revelar el historial y las direcciones futuras de su rama.
El segundo beneficio es un traspaso más exacto entre programas. Decir "estas son mis claves" deja sin declarar el tipo de salida y la ruta de derivación. Decir "este es el descriptor" le da al programa receptor la plantilla de script, los orígenes de las claves y el patrón de derivación juntos. Eso hace que una configuración multifirma o una ruta poco común dependa menos de los valores ocultos de un solo proveedor.
El tercer beneficio es la posibilidad de auditar. La política queda visible en una línea que se puede inspeccionar. Dos de tres está escrito como dos de tres. Taproot está escrito como Taproot. Un checksum puede detectar una copia dañada antes de que produzca una vista de wallet diferente. Bitcoin Core puede normalizar la expresión antes de guardarla o compararla.
Todavía queda trabajo operativo. El comando
importdescriptors
de Bitcoin Core exige un timestamp que le dice al nodo hasta dónde retroceder al escanear.
Un timestamp temprano puede hacer que el escaneo tarde más de una hora, mientras que
"now" salta el historial antiguo y solo es apropiado cuando los scripts nunca se usaron.
El comando también advierte que la importación exige un nuevo respaldo de la wallet. El
descriptor explica qué mirar, pero no conserva cada cambio posterior de la base de datos.
Lo que suele entenderse mal
"Un descriptor es solo una clave pública." Puede contener una clave pública, pero el tipo de script, la ruta de origen, la ruta hija y el checksum son información separada. Esa información alrededor de la clave es precisamente el objetivo.
"Un descriptor siempre es de solo lectura." No lo es. BIP 380 permite claves privadas y claves privadas extendidas dentro de las expresiones de clave. Copiar uno de esos descriptores en una nota, un chat o un documento en la nube puede equivaler a copiar material de firma. Hay que revisarlo antes de tratarlo como público.
"Un descriptor reemplaza la frase seed." Un descriptor público no puede firmar. Uno privado quizá pueda, pero sigue siendo una mala excusa para no probar el plan de recuperación. Las etiquetas, contactos, notas de transacciones y el último índice usado pueden vivir en otro lugar. Recuperar una multifirma también exige cada firmante necesario o su propio respaldo, no solo la política pública.
"El checksum prueba que el descriptor es confiable." Prueba que se detectaron errores probables de copia. No prueba quién creó el descriptor, que sus claves pertenezcan a los dispositivos previstos ni que dos de tres fuera la política acordada. Un descriptor equivocado con un checksum perfecto sigue equivocado.
"Importarlo encontrará todo enseguida." El escaneo empieza desde el timestamp indicado al importar. Una fecha demasiado tardía puede dejar invisibles pagos antiguos. Empezar al principio de la cadena da un resultado más completo, pero más lento. Un saldo ausente tras una importación puede ser un problema del límite del escaneo y no bitcoin perdido.
Dónde seguir
Conviene empezar por las salidas no gastadas si no está clara la diferencia entre el saldo de una wallet y los scripts que observa. Después se pueden leer los ejemplos del documento de descriptores de Bitcoin Core junto a BIP 380, en vez de copiar un descriptor de un tutorial.
Para un plan de recuperación real, hay que anotar qué puede hacer cada copia: observar, construir o firmar. Los descriptores privados merecen los mismos controles que una frase seed. La recuperación debe probarse con una wallet sin fondos significativos, incluidas sus ramas de recepción y cambio. La propiedad útil de un descriptor es su precisión. Solo ayuda cuando el proceso de respaldo conserva esa precisión hasta la restauración.