Saltar al contenido
buybitcoinsmart

Glosario / Referencia para desarrolladores

OP_CHECKMULTISIG

¿Qué es OP_CHECKMULTISIG?
OP_CHECKMULTISIG verifica un grupo de firmas frente a una lista de claves públicas en un solo paso, y los gastos Taproot no pueden usarlo en absoluto porque impide la verificación por lotes.

Se especifica en el BIP-11.

El byte 0xae es lo que hizo posible la custodia compartida: desapila un recuento de claves, esa misma cantidad de claves públicas, un recuento de firmas requeridas, esa misma cantidad de firmas y, después, un elemento de más. El consenso permite hasta 20 claves en una sola llamada. Es la razón por la que una empresa puede exigir que tres de cinco directivos aprueben un retiro sin que ninguno de ellos pueda actuar por su cuenta.

Cómo funciona

La verificación es una sola pasada por dos listas, no una búsqueda. El opcode (código de operación) recorre las firmas en orden y prueba cada una con las claves públicas sucesivas, así que las firmas tienen que aparecer en el mismo orden relativo que las claves a las que corresponden. Si se presenta un 2 de 3 válido con las dos firmas cambiadas de lugar, el script falla, una causa habitual de confusión cuando alguien construye a mano un gasto multisig.

La pila queda con un elemento de menos, y siempre ha sido así. La implementación original desapilaba un elemento adicional que nunca usaba, un error que no se podía eliminar sin romper todas las monedas existentes. Los firmantes aprendieron a apilar primero un elemento desechable, y BIP-147 cerró la maleabilidad resultante al exigir que ese elemento estuviera vacío, a partir del bloque 481.824.

Es en el cómputo del costo donde se nota. Una llamada simple se contabiliza como 20 operaciones de firma sin importar cuántas claves contenga realmente, salvo que la preceda inmediatamente un opcode de número pequeño, en cuyo caso se contabiliza ese número. Un bloque está limitado a 80.000 unidades de costo de operaciones de firma, y la política de retransmisión permite como máximo 15 de ellas en una sola entrada pay-to-script-hash. Ese número de la política, y no el límite de 20 del propio opcode, es la razón por la que las direcciones de script llegan como máximo a quince cofirmantes.

Tapscript lo retiró de plano. BIP-342 hizo que el opcode y su variante VERIFY fallen en cuanto aparecen dentro de una hoja de Taproot, porque verificar un lote de firmas Schnorr frente a una lista en una sola operación anula la verificación por lotes que hace que Schnorr valga la pena.

Dónde aparece

La salida 2 de 2 que financia cada canal Lightning usa OP_CHECKMULTISIG, lo que por sí solo sitúa el opcode en una gran parte de los gastos con script de la red. Las tesorerías corporativas, las configuraciones de escrow (depósito en garantía) de los mercados entre pares más antiguos y el almacenamiento en frío de los exchanges construido antes de Taproot también lo usan, normalmente como un 2 de 3 dentro de un hash de script.

Las llamadas simples, en las que las claves están directamente en la salida sin ningún hash delante, son estándar para la retransmisión con hasta tres claves y casi nunca se usan, porque el remitente paga por cada clave y toda la configuración es pública antes de que se mueva una sola moneda. En 2014 ese formato se convirtió brevemente en una forma de almacenar archivos en la cadena, y en parte por eso los debates sobre el almacenamiento de datos siguen resurgiendo cada vez que alguien toca la política de retransmisión.

Si usted está configurando ahora una custodia compartida, lo más probable es que su billetera genere una configuración Taproot con la alternativa por recuento, o un script P2WSH si la compatibilidad importa más que las comisiones.

OP_CHECKMULTISIG frente a multisig P2SH

OP_CHECKMULTISIG es una instrucción y el multisig P2SH es una forma de empaquetarla. El opcode dice cómo se comprueba un quórum; el empaquetado dice que el quórum queda oculto tras un hash y se revela en el momento del gasto. La misma instrucción puede aparecer en una salida simple con las claves a la vista, en un script de canje detrás de una dirección que empieza por 3 o en un script de testigo detrás de una dirección que empieza por bc1q, y los tres casos difieren enormemente en costo y privacidad aunque ejecutan una lógica de verificación idéntica. Lo que no se puede hacer es usar la instrucción en una hoja de Taproot, y por eso los quórums modernos se construyen con un opcode completamente distinto.

No confundir con

Preguntas frecuentes

¿Por qué falla mi gasto multisig si todas las firmas son válidas?

Casi siempre porque las firmas están en el orden equivocado. El opcode recorre las dos listas en paralelo, así que las firmas deben aparecer en el mismo orden relativo que sus claves públicas, y no retrocede para volver a probar una clave anterior.

¿Se está eliminando este opcode de bitcoin?

Sigue funcionando en los scripts heredados (legacy) y en los scripts SegWit de versión 0, y seguirá haciéndolo, ya que de él dependen las monedas existentes. Las hojas de Taproot no pueden usarlo, así que los quórums nuevos se construyen con el opcode OP_CHECKSIGADD, que cuenta las firmas verificadas de una en una.

Para seguir leyendo

Términos relacionados

Más en la sección Referencia para desarrolladores

Leer esta página en inglés