Multifirma

Curiosidad

1. ¿Por qué un script que requiere dos firmas saca tres elementos de la pila?
2. ¿Cómo puede una cadena de bytes vacía ser una regla de consenso en lugar de ser solo una convención?
3. ¿Qué cambia cuando diez claves se agrupan en una firma que parece indistinguible de la de un único firmante?

Explorar

1. Los scripts de multifirma exigen que al menos m firmas sean válidas con respecto a las n claves públicas listadas. El script de bloqueo indica m, las n claves públicas y n; OP_CHECKMULTISIG extrae n, esas n claves, m y luego m firmas, las cuales deben coincidir con las claves en el orden indicado. Si se proporcionan menos de m firmas válidas, el gasto es inválido.
2. Un error de codificación en la implementación original hace que OP_CHECKMULTISIG extraiga un elemento adicional del stack más allá de las firmas requeridas. Este elemento “falso” (dummy) se ignora durante la verificación criptográfica, pero debe estar presente; si falta, el stack sufre desbordamiento y la transacción falla. Los primeros usuarios empleaban OP_0 como este elemento de relleno, una convención que persistió durante años porque los nodos aceptaban cualquier valor en ese espacio.
3. BIP147 (NULLDUMMY), activado con SegWit en agosto de 2017, convirtió este vector de maleabilidad en una regla de consenso. El elemento ficticio debe ser ahora un array de bytes vacío. Cualquier valor no vacío, incluso un solo byte cero, hace que el script falle. Esto eliminó la posibilidad de alterar los IDs de las transacciones cambiando el contenido del elemento ficticio, estabilizando así el hash de la transacción para todas las confirmaciones posteriores.
4. Las reglas de estandarización determinan qué scripts multisig transmiten los nodos. Según la política por defecto de Bitcoin Core, las salidas de tipo bare multisig están limitadas a tres claves. Al estar envueltos en P2SH, los scripts multisig pueden utilizar hasta 15 claves (limitado por el script de canje de 520 bytes); en P2WSH, hasta 20. Esta distinción permite que las complejas estructuras de tesorería corporativa funcionen sin sobrecargar la capa básica de transacciones.
5. Dos herramientas más recientes reemplazan los patrones multisig antiguos. MuSig2 (BIP327, 2023), un protocolo independiente basado en las firmas Schnorr de Taproot, agrega múltiples claves públicas en una sola clave y genera una firma Schnorr estándar; on-chain, el gasto es indistinguible del gasto ordinario con una única clave de Taproot. Tapscript, que forma parte de Taproot mismo, añade OP_CHECKSIGADD, lo cual permite la verificación incremental de firmas sin el error de extracción extra del stack ni el límite de 20 claves de los opcodes antiguos.
6. Para inspeccionar estos mecanismos, abra un explorador de bloques y localice una transacción bare multisig anterior a SegWit. Observe el scriptSig: comienza con OP_0 seguido de las firmas. Compárelo con un gasto multisig P2WSH, donde el witness contiene un elemento vacío, las firmas y el script del witness que enumera las claves. Note cómo difieren los recuentos de bytes, lo cual refleja el costo de incluir la lista completa de claves en la salida frente a la entrada.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• BIP147: Dealing with dummy stack element malleability
• BIP327: MuSig2 for BIP340-compatible Multi-Signatures
• BIP342: Validation of Taproot Scripts