Qué es un quórum m-de-n

Se repite mucho que una multifirma «protege contra la pérdida y el robo». Depende del quórum. Una billetera (wallet) multifirma por script lista n claves públicas y un umbral m, y solo acepta un gasto que traiga m firmas de esas n claves. No es una regla de la red sobre personas o aparatos: lo exige el propio script.

Lo que aguanta sale de una resta. Puedes perder n menos m claves sin perder los fondos, y un ladrón necesita robar m. Un 2 de 3 sobrevive a una clave perdida y obliga a robar dos. Los extremos desmontan el eslogan:

• 1 de n. Cualquier clave basta. Aguanta pérdidas, pero no frena el robo.
• n de n. No sobra ninguna. Un 2 de 2 frena el robo de una clave, pero perder una es perderlo todo.
• m entre 2 y n menos 1. Solo aquí tienes las dos cosas a la vez.

Dos ideas que conviene separar. Una multifirma no es una seed repartida entre varias personas: cada clave es independiente y debe salir de su propia seed. Y la copia de una seed cuenta como su clave. Si guardas en el mismo cajón el aparato de una clave y la copia de otra, en ese cajón hay dos firmas.

También circula que «el máximo son 15 claves». Solo en P2SH, por el límite de 520 bytes del script. En P2WSH son 20, una multifirma desnuda solo es estándar hasta 3 y en Tapscript, multi_a llega a 999. Son techos técnicos, lejos de cualquier quórum manejable.

A cambio, la multifirma mete piezas nuevas: el descriptor, sin el cual las seeds no encuentran los fondos, la coordinación de cada gasto y la compatibilidad entre aparatos. Y las claves van fijas en el script: cambiar una exige otra multifirma.

En «Billetera multifirma» lee «¿Por qué una sola clave no siempre basta?», «Qué tolera un m de n», «El script y su elemento de más» (por encima: el orden de las firmas y el elemento vacío no hacen falta para el curso), la lista que cierra «Cuatro contenedores, cuatro límites» y «Riesgos nuevos que trae». El simulador de abajo no usa claves: solo cuenta.