Miniscript

Anna quiere acceder normalmente a sus monedas con su propia clave. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Anna también quiere habilitar una vía para Peter, que podrá gastarlas con su clave cuando hayan transcurrido 144 bloques desde la confirmación de esa salida. Esta intención se denomina spending policy: las reglas de gasto. Miniscript ayuda a expresarla con la precisión que necesita una cartera. Peter sigue necesitando su clave; esperar no la sustituye. Es un ejemplo sencillo de vías alternativas de acceso, no una transferencia automática ni un detector de que Anna haya perdido su clave. [1] [2] [10]

Una regla expresada con palabras todavía no es el programa que verifica la red. Un compilador puede elegir un Miniscript concreto y convertirlo en Bitcoin Script. Un Output Descriptor describe después los scripts junto con las claves y, cuando corresponde, sus rutas de derivación; también puede incluir una suma de comprobación para detectar errores de copia. Al gastar, la red verifica el script y los datos aportados, no la frase original. Miniscript no añade instrucciones ni modifica el consenso, las reglas compartidas de validez. Tampoco puede representar cualquier Bitcoin Script imaginable. [1] [3] [6]

Un bloque agrupa transacciones en un lote que se añade al historial compartido. En el ejemplo de Peter, los 144 bloques se cuentan desde la confirmación de la salida: una cantidad concreta con condiciones de gasto. No equivalen a un día exacto ni al tiempo desde que se creó la cartera. Miniscript expresa la espera relativa como older(n), mediante CSV y el campo nSequence de la entrada que gasta la salida. BIP 68 establece cómo se interpreta ese campo para comprobar la antigüedad. En cambio, after(n) utiliza CLTV y el nLockTime absoluto: una altura o un umbral temporal fijos. La cartera debe configurar correctamente los campos de la transacción y cumplir las demás condiciones. Los bloqueos por altura y por tiempo no pueden combinarse de manera incompatible; esperar no envía nada por sí solo. [1] [7] [8] [9] [11]

Mostrar las reglas no basta. La cartera debe proporcionar datos que cumplan una vía autorizada, como firmas o un secreto cuyo hash coincida con el exigido, llamado preimage. Un hash es una huella digital de los datos; aquí se comprueba si el secreto aportado produce la huella exigida. Este cumplimiento se denomina satisfaction; los datos necesarios forman parte del witness de la transacción. Al combinar ramas, puede ser necesario hacer que una condición parcial resulte falsa de la forma prevista para utilizar otra vía. Eso es una dissatisfaction y no significa que toda la transacción sea inválida. El software puede preparar el recorrido adecuado, pero no inventar una clave privada que falta ni un secreto desconocido. [1] [12]

PSBT es un formato para transmitir una transacción preparada y datos complementarios entre la cartera y los dispositivos que firman. Admitir PSBT no basta: tanto el programa como la Hardware Wallet deben comprender el descriptor y sus condiciones. Bitcoin Core incorporó la observación de Miniscript en P2WSH en la versión 24, la firma en la 25 y su uso en descriptores Taproot en la 26. Observar monedas no equivale a poder gastarlas. Durante la configuración, compruebe en una pantalla de confianza las claves, las firmas necesarias, las esperas y todas las vías alternativas, según las capacidades reales del dispositivo. [3] [4] [5]

Una Seed Phrase recupera claves, pero puede no explicar cómo se combinaron con otras claves y con el script de una condición personalizada. Es una copia de seguridad escrita como una secuencia de palabras a partir de la cual la cartera puede derivar sus claves. Conserve el descriptor exacto con su suma de comprobación, el mapa de claves, las rutas de derivación y la distinción entre direcciones de recepción y de cambio. Registre por separado la red, el intervalo de direcciones y el punto desde el que buscar en el historial. Un descriptor público no es una clave privada, pero puede revelar el historial de pagos. Antes de utilizar este esquema, pruebe la recuperación de una cartera de observación y cada vía de gasto prevista en un entorno Regtest o Signet. [5] [6]

pk(), older(), after() y sha256() representan firmas, esperas o la exigencia de un secreto. and_v(), or_d() y thresh() permiten combinar condiciones. Los envoltorios, como v:, ajustan la evaluación conservando el significado de la subexpresión. Los tipos B, V, K y W controlan cómo las partes intercambian elementos en la pila, el espacio de trabajo del script; no cualquier par encaja. La comprobación de tipos puede detectar una composición incompatible. No decide en quién debe confiar Anna ni si su vía de recuperación es sensata. [1] [2]

La estructura permite analizar de antemano el tamaño del script y del witness, las operaciones, las verificaciones de firmas y los elementos de la pila. Así se estiman los costes de las distintas vías y se detectan excesos sobre los límites permitidos. El contexto importa: P2WSH sitúa las condiciones dentro de SegWit, mientras que Tapscript corresponde a los scripts utilizados en Taproot. Sus límites no son idénticos. Además del consenso, cuentan las reglas habituales de retransmisión de transacciones. El análisis no certifica que cualquier cartera pueda ejecutar el procedimiento. [1]

La clave pública sirve para verificar firmas y no tiene que mantenerse en secreto. El análisis de malleability estudia si un tercero puede transformar una satisfaction válida en otra también válida. Sus garantías dependen de supuestos concretos: el atacante no tiene claves privadas de los participantes, no conoce más preimages que el usuario honesto y solo ve una satisfaction. También se presupone que no se repiten claves públicas y que rigen las reglas habituales de aceptación; un minero puede disponer de opciones que no tiene un nodo que retransmite. No es una garantía frente a todo participante malicioso, la pérdida de copias o un mal diseño de custodia. Esos problemas requieren atención aparte. [1]

Un compilador puede expresar las mismas reglas de distintas maneras, con tamaños diferentes de script y witness. Elige según un modelo de costes. Una anotación como 9@ en una rama del lenguaje de políticas indica una probabilidad relativa de uso; no es un número de firmas ni un permiso de la red. Otra compilación puede generar un script distinto y, por tanto, otras direcciones. Para recuperar la cartera no basta con volver a describir las reglas y compilarlas. Importan la representación exacta guardada, la comprobación de las direcciones derivadas y una vía de firma probada. [2] [5]