Billetera multifirma (multisig)

¿Por qué una sola clave no siempre basta?

Una seed phrase tiene un punto débil evidente: quien la copia, gasta. Y quien la pierde, pierde. Una billetera (wallet) multifirma reparte esa autoridad. El script de la salida lista varias claves públicas y un umbral, y la transacción solo es válida si aporta m firmas de esas n claves. Lo que protege no es una regla de la red sobre personas o aparatos. Es el propio script.

Esta entrada es la base conceptual y de Script. Cómo elegir m y n, repartir claves, recuperar y cuánto cuesta cada gasto en vbytes está en diseñar una multifirma, y la sintaxis del descriptor, en descriptores de salida.

Qué tolera un m de n

Lo que aguanta un esquema de m de n es aritmética, no una regla del protocolo. Soporta perder n menos m claves sin perder los fondos, y el robo de hasta m menos 1 claves sin que el ladrón pueda gastar. Un 2 de 3, por ejemplo, sobrevive a una clave perdida y obliga a robar dos.

Los casos límite desmontan la frase «protege contra la pérdida y el robo». Un 1 de n no protege contra el robo, porque cualquier clave basta. Un n de n no aguanta ninguna pérdida. Un 2 de 2 frena el robo de una clave, pero perder una es perderlo todo. Solo con m < n hay margen frente a la pérdida.

El script y su elemento de más

La plantilla original es el BIP-11, de Gavin Andresen (asignado el 18 de octubre de 2011, estado Deployed): el script de salida es m {pubkey}...{pubkey} n OP_CHECKMULTISIG. Un 2 de 3 con claves A, B y C queda así:

OP_2 <A> <B> <C> OP_3 OP_CHECKMULTISIG

Con claves comprimidas de 33 bytes (34 con el byte que anuncia su longitud), son 1 + 3 × 34 + 1 + 1 = 105 bytes, cuenta propia. Para gastar con A y C, el witness en una salida P2WSH es:

<vacío> <firma_A> <firma_C> <script>

Dos detalles rompen más multifirmas caseras que cualquier otra cosa.

El primero, el orden. En el código de Bitcoin Core (interpreter.cpp, consultado el 7 de octubre de 2026), OP_CHECKMULTISIG recorre firmas y claves en el mismo sentido. Si una firma no casa con la clave actual, pasa a la siguiente y no vuelve atrás. Así que las firmas tienen que ir en el mismo orden relativo que las claves del script. <firma_C> <firma_A> falla aunque las dos sean válidas.

El segundo, el elemento de más. El BIP-11 lo explica sin adornos: el OP_0 inicial «is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack». Ni el BIP-11 ni el código de Core lo atribuyen a nadie; el BIP-147 lo llama «design flaw». El propio BIP-11 justifica seguir usándolo porque cuesta solo 1 byte. Durante años ese elemento no se inspeccionaba por consenso y podía valer cualquier cosa; los nodos de Core ya no lo retransmitían desde la v0.10.0. Eso era una fuente de maleabilidad, es decir, que un tercero podía cambiar el identificador (el txid en scripts legacy; en SegWit, el wtxid) de una transacción sin invalidarla. El BIP-147 (Johnson Lau, asignado el 2 de septiembre de 2016, Deployed) lo cerró con la regla de consenso NULLDUMMY: el elemento tiene que ser el vector vacío, en scripts legacy y en witness. Se desplegó junto con SegWit, activado en el bloque 481.824 el 24 de agosto de 2017 (mempool.space y chainparams de Core). Cualquier dato que no sea vacío da hoy SCRIPT_ERR_SIG_NULLDUMMY.

El resto del mecanismo del script, con sus opcodes y su pila, está en Bitcoin Script.

Cuatro contenedores, cuatro límites

El mismo script de m de n se puede meter en cuatro formas distintas, y cada una trae su tope de claves. Ninguno es caprichoso. Cada uno sale de un motivo concreto, y conviene no mezclarlos, porque «el máximo son 15 claves» solo es cierto en uno de los cuatro.

Desnudo (BIP-11). El script entero va en la salida, a la vista de todos desde que se crea. La política de Bitcoin Core solo lo considera estándar hasta 3 claves (policy.cpp, consultado el 7 de octubre de 2026), y el BIP-383 limita igual el multi() de nivel superior en un descriptor. Es un límite de política, no de consenso, y se puede cambiar por nodo: -permitbaremultisig vale true por defecto en la rama principal a esa fecha, y con 0 el nodo rechaza estas salidas con la razón bare-multisig. Para guardar fondos no aporta nada frente a P2WSH.

P2SH (BIP-16). La salida es solo OP_HASH160 <hash de 20 bytes> OP_EQUAL. El script (el redeemScript) lo publica quien gasta, y esa era la idea: en palabras del BIP, mover «the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer». Rige desde el 1 de abril de 2012. El tope sale de una cuenta: un redeemScript no puede pasar de 520 bytes, y con claves comprimidas el BIP-16 calcula 3 bytes + 15 claves × 34 bytes = 513. Por eso el máximo práctico es 15 claves, aunque OP_CHECKMULTISIG acepte 20. Con claves sin comprimir bajan a 7 (BIP-383). La política añade otro tope, MAX_P2SH_SIGOPS de 15 operaciones de firma. El BIP-141 añade una pega de seguridad: los 160 bits del hash dejan una resistencia a colisiones de unos 2⁸⁰, cifra que el propio BIP considera ya «not infeasible anymore». Eso pesa sobre todo cuando otro participante aporta su clave después de ver las demás, porque puede probar claves hasta dar con una colisión (inferencia a partir del BIP-141, que solo da la cifra). Es un argumento para no crear multifirmas nuevas en P2SH puro.

P2WSH (BIP-141). La salida es un programa witness de versión 0 con el SHA256 del script, de 32 bytes. El script (el witnessScript) viaja en el witness, y ahí ya no pesa el límite de 520 bytes de un push. Por consenso, el tope es el de OP_CHECKMULTISIG: 20 claves (MAX_PUBKEYS_PER_MULTISIG). Por política, el script no pasa de 3.600 bytes y el witness no pasa de 100 elementos (policy.h, 7 de octubre de 2026). Un 20 de 20 cabe holgado: el script mide 2 + 20 × 34 + 2 + 1 = 685 bytes (el 20 no tiene opcode propio y ocupa 2 bytes) y el witness lleva 22 elementos: el vacío, 20 firmas y el script. La política cuenta 21, porque no incluye el script. Es una cuenta propia, no una cita. El BIP-143, que vino con SegWit v0, hace además que cada firma comprometa el importe de la entrada que firma. Era un paso para que un firmante sin conexión supiera la comisión, pero con varias entradas no basta (CVE-2020-14199, en firma sin conexión). Para las entradas Taproot lo cerró el BIP-341, cuya firma compromete los importes de todas las entradas. En P2WSH la defensa sigue siendo que el aparato vea las transacciones previas, y no todos lo exigen.

Existe también P2SH-P2WSH, un P2WSH envuelto en P2SH para billeteras antiguas: sigue la regla de 20 claves de P2WSH, pero su salida es un hash de 160 bits.

Tapscript (BIP-341/342). Aquí desaparece OP_CHECKMULTISIG. El BIP-342 lo desactiva: se comporta como OP_RETURN, para que quien lo siga usando «notice a problem immediately». En su lugar añade OP_CHECKSIGADD, «to compensate for the loss of OP_CHECKMULTISIG-like opcodes, which are incompatible with batch verification». El mismo 2 de 3, escrito como hoja multi_a(2,A,B,C) (BIP-387), es:

<A> CHECKSIG <B> CHECKSIGADD <C> CHECKSIGADD 2 NUMEQUAL

El witness lleva un hueco por clave, en orden inverso, vacío donde no se firma: <firma_C> <vacío> <firma_A> <script> <bloque de control>. Ya no hay elemento de más. Cada firma Schnorr se comprueba contra su propia clave, sin probar combinaciones, y eso permite verificarlas por lotes. El mismo 2 de 3 con CHECKSIGADD está también explicado en Taproot. Tampoco rige el tope de 10.000 bytes ni el de 201 opcodes, y el que manda es la pila, de 1.000 elementos: de ahí salen las 999 claves de multi_a. Es un límite de consenso, no de política. En Core, multi_a y sortedmulti_a existen desde la v24.0.

• Desnudo: 3 claves como máximo. Política.
• P2SH: 15 comprimidas (7 sin comprimir). Consenso por el push de 520 bytes y política por las sigops.
• P2WSH: 20 claves. Consenso.
• Tapscript con multi_a: 999 claves. Consenso.

Un límite de consenso por script no es lo mismo que un tope práctico. Las 20 claves de P2WSH y las 999 de Tapscript son techos técnicos, y con ellas no se crea un quórum manejable. Otros límites, como los 201 opcodes que cuentan las claves de CHECKMULTISIG, están en miniscript.

El orden de las claves

Como el script lista las claves en un orden concreto, dos billeteras con las mismas claves pueden generar direcciones distintas si no se ponen de acuerdo. El BIP-67 (Kerin, Rupp y de Vries, estado Complete) lo resolvió ordenando las claves comprimidas lexicográficamente según su representación binaria. El mismo conjunto de claves y el mismo m dan siempre el mismo script. sortedmulti en un descriptor hace lo mismo, y multi respeta el orden que se le da. Cuál usar y por qué cambia la dirección está en descriptores de salida.

La misma idea aparece donde nadie la llama billetera multifirma. La salida de financiación de un canal de Lightning es un P2WSH 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG, con las claves en orden lexicográfico y el witness 0 <sig1> <sig2> (BOLT-03, consultado el 7 de octubre de 2026). Es un 2 de 2 de manual.

Qué se ve en la cadena según el contenedor

Antes de gastar, una salida no enseña el umbral, solo un hash. Después de gastar, enseña casi todo, y lo que enseña depende del contenedor.

• P2SH: la salida es un hash de 20 bytes, igual que cualquier otro P2SH. Al gastar se publican el redeemScript (m, n y todas las claves) y las firmas.
• P2WSH: el programa de 32 bytes se distingue de P2WPKH (20 bytes), pero no de otros P2WSH, como la financiación de un canal de Lightning (BOLT-03). Al gastar se publican el witnessScript, el umbral, las n claves y las firmas, y verificando cada una contra las claves se sabe quién firmó.
• Tapscript con hoja multi_a: al gastar por la hoja se ven las claves y los huecos vacíos de las que no firmaron. Se revelan también la clave interna, la profundidad de la hoja y que no se usó el camino por la clave.
• Taproot por la clave, con MuSig2 o FROST: el gasto es indistinguible de una firma simple (BIP-341).

Esto corrige una idea muy repetida. Taproot no oculta por sí solo una multifirma por script. Lo que la oculta es agregar las firmas en una sola, cosa que exige cooperación de todos (MuSig2) o un esquema de umbral (FROST), y se explica en MuSig2 y FROST. El BIP-341 recomienda, si no se quiere camino por la clave, usar como clave interna un punto NUMS aleatorizado, para que, al gastar por una hoja, la clave interna no delate que el camino por la clave era imposible. Cuánto ocupa cada variante, con vbytes, y qué filtra la heurística del cambio, está en diseñar una multifirma.

Riesgos nuevos que trae

Una multifirma quita un punto único de fallo y mete otros. Los principales:

• El descriptor. El script lleva todas las claves públicas, el umbral y el orden. Con m seeds y sin esa información no se reconstruyen las direcciones. Por eso el descriptor es parte de la copia.
• La coordinación. Cada gasto necesita juntar m firmantes, normalmente con una PSBT. Más claves y más sitios significan más logística y más ocasiones de equivocarse al montar o al recuperar. Ordekian et al. (AFT 2024, §7.1.3) lo resumen así: pedir más firmas pone más difícil el robo, pero la billetera puede costar más de montar y ser más fácil que el dueño pierda los fondos (traducción propia). Unchained, que vende multifirma con una de las claves en su poder, dice que con su bóveda es fácil. Las dos cosas pueden ser ciertas a la vez: la dificultad baja con ayuda, pero no desaparece.
• La compatibilidad. No todos los aparatos ni todo el software admiten P2WSH multifirma, multi_a o miniscript. Hay ejemplos con fecha en diseñar una multifirma.
• La inmutabilidad. Las claves van fijas en el script. Cambiar una exige crear otra multifirma y mover los fondos con una transacción, como explica la sección «Si falta una clave» de esa misma entrada.

Para qué se usa

Seguridad personal. Tres claves en tres aparatos o lugares, con un 2 de 3. Si se pierde una, las otras dos y el descriptor permiten recuperar el acceso.

Custodia compartida. Una empresa o una tesorería puede exigir que dos de tres responsables firmen cada gasto, de modo que nadie tenga el control total. Algunos servicios guardan una de las claves, y eso se analiza en el apartado de custodia colaborativa de diseñar una multifirma.

Herencia. Un 2 de 3 con el titular, un familiar y un abogado permite que los herederos accedan con dos claves y el descriptor. Pero dos cofirmantes podrían ponerse de acuerdo en vida del titular, y ese riesgo se trata en herencia de bitcoin.

Canales de Lightning. El 2 de 2 de la transacción de financiación, ya visto arriba.

Si se quiere que el quórum decaiga con el tiempo, existe la variante con timelocks de billeteras con timelock.

Qué significa esto para ti

Antes de crear una multifirma, decide el contenedor y apúntalo. Hoy lo normal es P2WSH nativo, o una hoja de Tapscript si todos los aparatos lo admiten, y P2SH puro queda para lo que ya existe. Comprueba que el software y los aparatos hablan el mismo idioma, guarda el descriptor con el mismo cuidado que las seeds y, si dudas de que merezca la pena, vuelve a tu modelo de amenazas. Para ver qué pasa con cada quórum cuando se pierden o se roban claves, está el simulador de quórum. Y para decidir el reparto, el paso siguiente es diseñar una multifirma.