Diseñar una multifirma: quórum, reparto y recuperación

Dos de tres, ¿y después qué?

Montar una multifirma lleva una tarde. Diseñarla bien lleva más, porque deshacer cada decisión cuesta una transacción. Cuántas claves, cuántas hacen falta, en qué sitios, de qué fabricantes, qué papel hay que guardar. Qué es una multifirma y cómo se escribe su descriptor están en sus entradas. Aquí se trata de elegir, y de comprobar que lo elegido se puede recuperar.

Elegir m y n

No hay un estándar que diga qué quórum usar. Sale de una aritmética sencilla. Con un quórum de m de n, un ladrón necesita m claves para gastar, y tú puedes perder n menos m sin perder los fondos.

• 2 de 3: aguanta perder una clave y obliga a robar dos. Es el punto de partida para una persona sola.
• 3 de 5: aguanta perder dos y obliga a robar tres. A cambio, cinco aparatos, cinco sitios y un gasto más caro (más abajo, con números).
• n de n: no aguanta ninguna pérdida. Perder una clave es perderlo todo.
• 1 de n: cualquier clave basta, así que no protege contra el robo.

Que un 3 de 5 resista más no lo hace siempre mejor. Hay más sitios que vigilar y más gente o más aparatos que coordinar. Para una persona sola, un 2 de 3 bien repartido suele ser lo razonable. Una familia añade el riesgo de que dos miembros se pongan de acuerdo. El caso de los herederos está en herencia de bitcoin. En una empresa, el umbral suele seguir las firmas autorizadas.

Repartir: lugares y fabricantes

La regla de los lugares tiene dos mitades. Contra el robo, en ningún sitio debe haber m piezas juntas que basten para firmar. Contra la pérdida, ningún sitio debe guardar tantas que, si lo pierdes, te queden menos de m (o ninguna copia del descriptor). La copia de la seed phrase (la seed) de una clave cuenta como esa clave. En un 2 de 3 las dos mitades coinciden: ninguna pareja de claves duerme en el mismo cajón. En un 3 de 4 no. La primera mitad permite dos claves en el mismo sitio, pero si ese sitio arde quedan dos, y no bastan.

Sparrow lo explica así: con los aparatos repartidos, «eres mucho menos vulnerable a ataques físicos», sobre todo si llegar a cada sitio lleva tiempo o exige pasar controles de seguridad (Sparrow, Best Practices, consultado el 7 de octubre de 2026). El ejemplo de la bóveda de 5 claves de Casa reparte móvil, casa, oficina, caja de seguridad y una clave en manos de Casa (Casa, documentación actualizada el 24 de octubre de 2023).

Con los fabricantes pasa algo parecido. Si las tres claves viven en aparatos del mismo fabricante, un fallo de firmware o de entropía puede afectarlos a la vez y dejar el quórum sin efecto. Sparrow recomienda aparatos de varios fabricantes para que una vulnerabilidad en uno no comprometa todo el montaje. El caso de entropía débil en Coldcard y la cita de Dark Skippy en modelo de amenazas muestran por qué importa.

La diversidad tiene un techo: la compatibilidad. No todos los aparatos admiten lo mismo (registro de política BIP-388, multifirma en Taproot, miniscript). Según la lista de Liana, Jade y Jade Plus no admiten sus descriptores Taproot, y con Liana no funcionan si se configuraron en modo QR, porque en ese modo no se comunican por USB (Liana, SIGNING_DEVICES.md, consultado el 7 de octubre de 2026). No parece cosa de Liana: a 7 de octubre de 2026, el registro de cambios de Jade solo recoge Taproot de clave única (BIP-86, desde el firmware 1.0.34), y su última versión es la 1.0.41, del 22 de agosto de 2026. Antes de comprar, comprueba que tus aparatos hablan el mismo idioma. Más sobre ellos en hardware wallets y firma sin conexión.

Qué hace falta para recuperar

Recuperar una multifirma exige dos cosas: al menos m claves, sea como seeds o como aparatos que las contengan, y el descriptor completo. Por qué el descriptor es parte de la copia está en descriptores de salida. Si se perdió, se puede rehacer con las n xpub, cada una con su huella y su ruta de origen (por ejemplo 48'/0'/0'/2'), más el umbral, el tipo de script (wsh, sh-wsh o tr) y si es multi (y entonces en qué orden van las claves) o sortedmulti. Sin huella ni ruta, un aparato no reconoce su propia clave dentro de la multifirma.

Las rutas de esa familia las propone el BIP-48 (estado Deployed en octubre de 2026, asignado el 16 de diciembre de 2020). El tipo 1' es P2SH-P2WSH y el 2' es P2WSH nativo, el recomendado por defecto. El BIP-48 se escribió para fijar una práctica que ya existía, y no define un tipo para Taproot. En Taproot, la ruta depende del programa que la creó, así que no se puede adivinar: apúntala junto a las xpub, por si tienes que rehacer el descriptor (más en rutas de derivación).

El descriptor se encuentra en la práctica con varias formas: el descriptor del BIP-380, la política del BIP-388, el fichero BSMS del BIP-129, el «configuration file» de Unchained y el correo «Sovereign Recovery» de Casa. El BSMS, estado Complete, sirve además para montar la multifirma: es un protocolo de dos rondas en el que cada firmante entrega su clave con su origen y una firma, y después el coordinador reparte el descriptor y todos comprueban que da la misma primera dirección (BIP-129, consultado el 7 de octubre de 2026).

Al registrar la multifirma, cada aparato enseña el quórum y las xpub. Compáralas enteras y en el mismo formato con las que mostró cada aparato al exportarlas. Si alguno solo dio un QR o un fichero, usa la que ese mismo aparato marca como suya en su pantalla de registro (Jade con un asterisco, Coldcard con su huella). Nunca las compares con un fichero del ordenador. El paso a paso está en firma sin conexión.

Si falta una clave

El script fija las claves, así que una clave perdida no se «sustituye» dentro de la billetera (wallet). Qué hacer depende de lo que pasó. Si se rompió el aparato pero conservas su seed, depende de dónde nació la clave. Si era de una hardware wallet, restáurala en otra hardware wallet vacía (con un Trezor Model One, con la recuperación avanzada) y, si el aparato guarda la multifirma, vuelve a registrarla (comprobando el quórum y las xpub). Y sigues como estabas. Si nació en una app, y te hace falta para llegar al umbral, restáurala en esa misma app instalada en un aparato limpio, y nunca en una hardware wallet. Como esa seed vivió en un móvil o un ordenador, recuperar una billetera la da por expuesta: prepara antes el destino y cambia esa clave como en el caso siguiente. Si perdiste el aparato o te lo robaron, aunque conserves su seed (un aparato perdido sigue teniendo la seed dentro), o si la clave se perdió o no hay copia, toca crear otra multifirma con una clave nueva, con su propio descriptor, que también se guarda, y mover los fondos con las claves que quedan. Cuesta una transacción. El procedimiento, con sus cautelas, está en recuperar tu billetera. Y una regla que no cambia: no borres ningún firmante de la multifirma antigua hasta que los fondos estén confirmados en la nueva.

Mientras no migres, un 2 de 3 que ha perdido una clave ya no aguanta otra pérdida. Y si alguien encontró la clave perdida, le basta con robar una más. Si el cosignatario es una persona que no colabora o ha muerto, el caso es el mismo: mientras queden m claves, se migra. Si quedan menos de m, los fondos se pierden, salvo que exista una ruta con timelock (billeteras con timelock).

Custodia colaborativa

Algunos servicios guardan una de las claves, y eso cambia la recuperación sin cambiar la naturaleza del quórum. Casa ofrece bóvedas 2 de 3 y 3 de 5, y en las dos guarda una de las claves, la «Recovery Key». Según su ayuda, esa clave nunca firma operaciones normales. Solo sirve para sustituir una clave perdida: firma el paso de los fondos a una bóveda nueva después de una espera obligatoria (7 días tras responder unas preguntas de seguridad o, en los planes Premium y Private Client, una videollamada y dos días) y no hace falta para recuperar sin Casa (Casa, mayo de 2026). Su portada la anuncia también como «Co-signer for the everyday», cofirmante para el día a día, sin más detalle (consultada el 7 de octubre de 2026). Vale lo que dice la ayuda: no cuentes con esa clave para un pago urgente. Si Casa cierra, se recupera con el correo «Sovereign Recovery» (claves públicas y rutas, sin claves privadas), los aparatos y Sparrow o Electrum. La vía más rápida es importar en Sparrow el descriptor que exporta la app (Casa, 21 de mayo de 2026). En Unchained, el cliente tiene dos de las tres claves y Unchained una. Para recuperar sin ellos hacen falta el fichero de configuración y esas dos claves (Unchained, consultado el 7 de octubre de 2026). Nunchuk dice guardar «solo una clave» y Bitcoin Keeper ofrece una «Server Key» que no puede gastar sola (consultados el 7 de octubre de 2026).

Dos aclaraciones. Ninguno es un custodio: con una clave sola no pueden mover tus fondos. Pero no los des por ciegos. Quien tiene todas las xpub de la multifirma, o el fichero de configuración, ve el saldo y el historial completos, y Unchained lo avisa de su propio fichero. Y si el proveedor desaparece, lo que necesitas son tus propias claves hasta llegar al umbral y el fichero de configuración o el descriptor. La página de ayuda de Unchained sobre ese fichero se contradice (consultada el 7 de octubre de 2026). Dice que no recomienda guardar una copia a largo plazo y que la mayoría de sus clientes no lo descarguen. Pero también dice que hay que hacer copia, porque sin el fichero y tus dos claves no se recupera si Unchained desaparece, y recomienda guardarlo en un USB sin conexión o en un disco cifrado. Lo que no admite duda es esto: si no tienes ni el fichero ni el descriptor, no hay recuperación sin Unchained. Casa, en cambio, pide guardar su correo «Sovereign Recovery», que cumple la misma función (21 de mayo de 2026). Así que guárdalo desde el primer día, fuera de la nube y con el mismo cuidado que el descriptor, porque con él y dos de tus claves se puede gastar.

Cuánto cuesta: un ejemplo con números

Una multifirma por script ocupa más que una clave sola. Las comisiones se pagan por vbyte (vB). Para calcularlo se usan unidades de peso (WU): cada byte fuera del witness cuenta 4 y cada byte dentro cuenta 1, y el total se divide entre 4 (lo explican SegWit y comisiones de transacción). Estas cifras son un cálculo propio a partir de BIP-141, BIP-341 y BIP-342, con cuatro supuestos: firmas ECDSA de 72 bytes (con el byte de sighash), firmas Schnorr de 64 (sighash por defecto), un árbol Taproot de una sola hoja (salvo en el caso de MuSig2, que dice el suyo) y salidas de 43 vB, que es el tamaño tanto de P2WSH como de P2TR.

• P2WSH 2 de 3: script de 105 bytes y dos firmas. Cada entrada pesa 164 WU fuera del witness y 254 WU dentro: 104,5 vB.
• P2WSH 3 de 5: script de 173 bytes y tres firmas, 139,75 vB por entrada.
• P2SH-P2WSH anidado: unos 35 vB más por entrada que P2WSH (aunque su salida, de 32 vB, es 11 más barata).
• Taproot, hoja única con multi_a: 2 de 3 en 108,75 vB y 3 de 5 en 142,25 vB.
• Taproot, gasto cooperativo por la clave (MuSig2 o FROST): 57,5 vB, lo mismo que una clave sola.
• Taproot, 2 de 3 con MuSig2: clave interna musig(A,B) y dos hojas, musig(A,C) y musig(B,C), cada una a un nivel de profundidad. Si firman A y B, el gasto va por la clave y cuesta 57,5 vB. Si firma otro par, va por su hoja (script de 34 bytes, control block de 65) y cuesta 82,75 vB.

Si cambian los supuestos, cambian las cifras. Cada byte menos en una firma ECDSA resta 0,25 vB: con firmas de 71 bytes (las «low-R» que generan Bitcoin Core y muchos aparatos), el 2 de 3 baja a 104 vB, y con 73 sube a 105. Cada nivel más de profundidad en el árbol Taproot suma 8 vB, y un sighash explícito, 0,25 vB por firma Schnorr.

Una transacción con una entrada y dos salidas P2WSH (pago y cambio) suma 10,5 vB de cabecera y 86 vB de salidas. Con un 2 de 3 son 804 WU, 201 vB justos. Con un 3 de 5 son 945 WU, y como BIP-141 redondea hacia arriba, 237 vB: un 18 % más. Con una tarifa hipotética de 10 sat/vB, serían 2.010 sat frente a 2.370 sat. La tarifa es un supuesto, no una cifra de red. Si el pago va a una dirección P2WPKH, de 31 vB, las dos bajan a 189 y 225 vB. Con más entradas, la diferencia relativa crece.

La conclusión: en los quórums habituales (2 de 3, 3 de 5), una hoja multi_a no es más barata que P2WSH. Lo que ahorra es una sola firma agregada, por la clave (57,5 vB) o por una hoja musig() (82,75 vB), y eso exige MuSig2 o FROST (MuSig2 y FROST). MuSig2 solo da n de n por la clave: un 2 de 3 necesita hojas de reserva y solo esconde el par de la clave interna. FROST sí da umbral, pero con claves generadas en grupo (DKG o dealer), no con tres seeds independientes, y su BIP, el 445, sigue sin fusionar en octubre de 2026. Todo el detalle, en Taproot.

Lo que se ve en la cadena

Una salida P2WSH se reconoce desde el principio como hash de script: su dirección bc1q es más larga, porque el programa mide 32 bytes frente a los 20 de P2WPKH (BIP-141, BIP-173). Al gastar, se publican el umbral, las n claves públicas y qué firmas hubo. Si el pago va a otro tipo de dirección, o a otro script, y el cambio vuelve a la multifirma, la heurística del tipo de script delata cuál es el cambio. La wiki de Bitcoin pone un ejemplo: una multifirma 2 de 3 que paga a una dirección 2 de 2 y se devuelve el cambio. El script distinto señala el pago, y el otro queda marcado como cambio (consultada el 7 de octubre de 2026). En Tapscript, gastar por una hoja revela esa hoja (con una sola hoja multi_a, el umbral y las n claves, como en P2WSH), la clave interna, la profundidad de la hoja y que se gastó por script. Las demás hojas quedan ocultas mientras no se gasten (y si reutilizas la dirección, pueden salir más). Para ordenar los gastos, coin control, y para tus propias anotaciones, las etiquetas BIP-329. Los tipos de dirección están en tipos de direcciones.

Qué significa esto para ti

Antes de mover un satoshi, escribe tu diseño en una hoja: m y n, dónde está cada clave, de qué fabricante es y dónde está cada copia del descriptor. Comprueba que ningún sitio reúne m claves y que perder cualquiera te deja m claves y un descriptor. Después, haz el simulacro con una cantidad pequeña: restaura cada seed que viva en una hardware wallet en otra de repuesto vacía (nunca en el ordenador ni en el móvil; una clave nacida en una app se prueba en esa misma app del mismo aparato, con el teclado del sistema, antes de mandar nada a la multifirma, ni siquiera la cantidad de prueba, y solo se borra para probarla si ninguna billetera de esa seed tiene fondos, tampoco con passphrase) y el descriptor en otro programa, sin borrar ningún aparato de la multifirma (cómo, en descriptores de salida). Al terminar cada prueba, borra el repuesto: con la seed dentro es una copia más de esa clave. Mejor que falle en el ensayo que con fondos reales. Para ensayar qué pasa si pierdes o te roban claves, usa el simulador de quórum. Y recuerda que recuperar no es probar. Si te roban o pierdes el aparato de una clave, esa clave queda expuesta: solo se restaura si hace falta para llegar al umbral y mover los fondos, y entonces en un aparato limpio, nunca en una hardware wallet (ver recuperar una billetera).