Script de canje

BIP-16 permitió a un remitente pagar a un hash de 20 bytes en lugar de a un contrato entero, y el script de canje es el contrato que representa ese hash. Tiene que caber en un solo elemento de la pila, así que 520 bytes es el límite absoluto. Si pierde esos bytes, sus claves privadas no valen nada, y eso convierte el script de canje en parte de su respaldo y no de su software.

Cómo funciona

Un script de canje es invisible mientras las monedas no se mueven. La salida que las contiene solo incluye un hash y un patrón que el consenso reconoce, y que toda la red hace cumplir desde el 1 de abril de 2012, en el bloque 173.805. Nadie que le pague a usted se entera de nada sobre las condiciones, y un explorador de bloques tampoco.

El script se revela en el gasto. El script de desbloqueo apila los argumentos que necesite el contrato y termina con el propio contrato serializado. Un nodo que valida toma ese último elemento, calcula su hash, compara el resultado con el hash de la salida y solo entonces deserializa el elemento y lo ejecuta como código sobre el resto de la pila. Ambas etapas deben superarse, y como el campo que lo transporta no puede contener más que inserciones de datos, el propio script no puede colar ningún comportamiento antes de que se compruebe.

El script de canje más común que existe no es un contrato en absoluto. A partir de 2017, las billeteras que querían el ahorro de SegWit sin dejar de poder recibir pagos de software antiguo anidaron un programa de testigo dentro de un hash de script, así que el script de canje ocupa 22 bytes: un byte de versión y un hash de clave de 20 bytes, sin nada que ejecutar. Millones de direcciones de retiro de exchanges que empiezan por 3 esconden exactamente eso y nada más.

Dónde aparece

Bitcoin Core le entrega uno cada vez que usted crea una dirección de script, y su comando decodescript convierte la cadena hexadecimal de nuevo en una representación en ensamblador (ASM) legible. En un descriptor, el script se escribe de forma explícita como sh(wpkh(...)) o sh(multi(...)), que es la forma moderna de registrarlo, porque las billeteras de descriptores llegaron en Bitcoin Core 0.21.0, en enero de 2021, y dejaron obsoleto el viejo hábito de importar direcciones sueltas.

El modo de pérdida es real y concreto. Una frase semilla regenera claves. No regenera un script arbitrario ni puede indicarle las claves públicas de los demás cofirmantes, así que una configuración 2 de 3 en la que cada participante solo ha guardado su propia semilla es imposible de gastar. Hay quien ha perdido monedas teniendo un juego completo de claves privadas y ningún registro del script en el que esas claves estaban organizadas. Guarde el descriptor junto a cada respaldo de semilla y restaure a partir de él una vez, con un monto pequeño, antes de que la dirección contenga algo que usted echaría de menos.

Lo otro que conviene saber es el límite de tamaño. Quince claves públicas comprimidas, más sus prefijos de inserción de datos y los opcodes (códigos de operación) que las rodean, suman 513 bytes, que caben justo; una decimosexta ya no cabe. Es ese techo, y no una regla sobre multisig, lo que limita una dirección de script a quince cofirmantes.

Script de canje frente a script de testigo

Un script de canje y un script de testigo ocupan el mismo lugar conceptual en dos épocas distintas, y la diferencia está en por dónde viajan los bytes y en qué los fija. Un hash de 160 bits fija el script de canje, que viaja en el script de desbloqueo a cuatro unidades de peso por byte. Un SHA-256 completo de 256 bits fija el script de testigo, que viaja en el testigo a una unidad de peso por byte, por lo que la misma política cuesta aproximadamente la cuarta parte al gastar. Una configuración anidada usa ambos a la vez: el script de canje es el programa de testigo de 34 bytes y el script de testigo es el contrato real. Si está registrando el respaldo de un multisig SegWit anidado, necesita tener ambos por escrito, no uno solo.