Bitcoin: un borrador propone claves internas Taproot reproducibles desde las reglas del monedero

Una propuesta abierta sin adopción anunciada

Una solicitud de contribución abierta el 1 de noviembre de 2026 en el repositorio de propuestas de mejora de Bitcoin presenta una convención para claves internas Taproot de monederos. Numerada 2340 en GitHub, sigue abierta y sin fusionar durante nuestra comprobación. Ese número identifica la solicitud, no un número de BIP asignado. El documento tiene estado Draft y busca que distintos programas reproduzcan una construcción a partir de las mismas reglas del monedero.

El marcador propuesto es el guion bajo, utilizado en lugar de una clave interna cuya clave de firma se desconoce. Afecta a una vía concreta de gasto Taproot, no a una prohibición de gastar todos los bitcoins del monedero. Las demás condiciones de los scripts siguen siendo determinantes. El borrador aclara que construir esta clave no exime a los programas de comprobar por separado la validez y los requisitos de la política que la rodea.

Reconstruir sin otro secreto aleatorio

El problema descrito afecta a monederos que quieren inutilizar esa vía interna evitando una clave fija reconocible cuando un gasto revela los datos correspondientes. Algunos métodos utilizan un valor aleatorio que debe conservarse. El texto propone derivar los parámetros públicos de una forma normalizada de la política. Dos implementaciones podrían así reproducir la clave interna con esa política y la ruta de derivación, sin guardar ese secreto adicional.

La construcción utiliza mecanismos existentes, incluidas las claves extendidas de BIP 32 y un punto descrito en BIP 341 cuyo logaritmo discreto se desconoce. Su compromiso criptográfico abarca las claves y la estructura de las reglas: umbrales, plazos, funciones u organización del árbol. El objetivo es distinguir políticas que emplean las mismas claves bajo condiciones diferentes. No pretende reconocer automáticamente como idénticas todas las reglas que produzcan resultados equivalentes.

La copia de seguridad necesita la política

Esa reproducibilidad tiene límites. El documento indica que una copia de la semilla por sí sola no reconstruye la política del monedero. También explica que un observador que conozca o adivine la política completa podría reconstruir parámetros públicos y enumerar algunas claves internas. Por tanto, la propuesta no garantiza privacidad absoluta. Su seguridad depende, entre otros aspectos, del supuesto criptográfico sobre el punto inicial y del cumplimiento exacto de las reglas de derivación.

Adoptar esta convención cambiaría las direcciones de una política existente. Por ello, el borrador exige tratar el resultado como un descriptor distinto y conservar el original para vigilar y gastar los fondos recibidos anteriormente. La solicitud incluye una implementación Python y vectores de prueba, pero su finalidad declarada es la demostración y la interoperabilidad, no el uso en producción. El depósito de hoy abre una revisión técnica; no demuestra aprobación colectiva, compatibilidad universal ni despliegue en los monederos.