133 / 736MuSig2

MuSig2

Autorizar un pago juntos sin compartir claves privadas

Dos personas pueden autorizar juntas un pago en bitcoin sin entregarse sus claves privadas. MuSig2 convierte esa colaboración en una sola firma. En la blockchain puede parecer un pago Taproot corriente, aunque la decisión haya sido compartida.

MuSig2 permite que varias personas creen juntas una firma Schnorr que acredita la aprobación de un mensaje concreto sin revelar sus claves privadas. El procedimiento de BIP327 utiliza dos rondas de comunicación. Combina las claves públicas en una clave agregada y las contribuciones en una firma compatible con BIP340. El modelo básico es n-of-n: todos los firmantes deben contribuir.

Imagine una tesorería donde Alice y Bob deben aprobar cada pago. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. Un Multisig convencional basado en scripts puede revelar varias claves y firmas en la transacción. Con MuSig2, cada persona conserva su clave privada y contribuye a una firma conjunta. La red verifica un único resultado. Se ahorra espacio y trabajo de verificación en la blockchain; la coordinación entre los participantes sigue siendo necesaria. Jonas Nick, Tim Ruffing y Yannick Seurin presentaron el protocolo en un trabajo publicado en octubre de 2020. [3] [2] [10]

MuSig2 no es, por sí solo, una configuración 2-of-3 donde cualquier pareja pueda suplir al tercer firmante ausente. En su modelo n-of-n debe contribuir cada miembro del grupo. Un participante no disponible o que se niegue puede detener la colaboración. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Si la cartera debe funcionar también en ese caso, necesita otra vía de gasto o mecanismo de firma diseñado de antemano; el nombre MuSig2 no lo proporciona automáticamente. [1] [8]

Antes de firmar, los participantes construyen una clave pública agregada. La clave pública sirve para verificar firmas y no tiene que mantenerse en secreto. En la primera ronda intercambian nonces públicos, contribuciones de un solo uso para preparar la firma. En la segunda crean e intercambian firmas parciales para el mismo mensaje y contexto, y las combinan en la firma final. Bajo las condiciones del protocolo, la primera ronda puede prepararse antes de conocer el pago. Pero antes de crear su firma parcial, cada participante debe comprobar la transacción concreta, especialmente el destinatario, el importe y la comisión. Preparar no significa autorizar un pago desconocido: comprobarlo después de firmar llega demasiado tarde. [1] [3]

Una suma ingenua permitiría que un atacante eligiera su clave pública para aprovecharse de las claves ajenas. MuSig2 utiliza pesos numéricos, llamados coeficientes, derivados de la lista de claves. KeyAgg también tiene en cuenta su orden; la aplicación puede usar KeySort para establecer un orden común. Todos deben emplear la misma lista y las mismas reglas, o no calcularán la misma clave agregada. [1] [5]

Aquí nonce no significa contador de minería. Es material de firma de un solo uso: pubnonce se comparte y secnonce permanece con el firmante. Nunca se debe reutilizar un nonce secreto en otra llamada a Sign. Dos firmas parciales obtenidas al reutilizarlo pueden revelar la clave privada. Cambiar el mensaje o repetir un pago aparentemente idéntico no es una excepción segura. [1] [7]

Un cálculo criptográfico correcto no basta si, tras reiniciarse, la aplicación restaura un secnonce usado desde una copia o lo entrega a dos tareas simultáneas. Libsecp256k1 invalida el nonce secreto sobrescribiéndolo al firmar, pero una copia fuera de su control puede eludir esa protección. La gestión del estado debe evitar la reutilización durante errores, recuperaciones y operaciones concurrentes. La clave privada sí puede emplearse repetidamente; el componente de un solo uso es el nonce. [7]

Un coordinador puede recoger nonces públicos y firmas parciales y facilitar el intercambio. Con el protocolo usado correctamente, eso no le permite firmar en lugar de un participante honesto, aunque sí puede frustrar el proceso. Cada firmante debe comprobar qué firma. Verificar firmas parciales puede ayudar a detectar problemas, pero requiere las contribuciones públicas originales y el contexto correcto; el nonce agregado por sí solo no identifica al responsable. [1] [7]

El resultado es una firma BIP340 de 64 bytes. La key path de Taproot es una vía de gasto en la que la red verifica la firma respecto a la clave fijada en la salida, sin revelar un script alternativo. Si no se utiliza el modo predeterminado, tras la firma aparece un byte de tipo sighash. Este determina qué partes de la transacción quedan vinculadas a la firma, de modo que cambiarlas la invalidaría. La firma por sí sola no revela cuántos participantes hay ni sus claves individuales. MuSig2 no oculta los importes, todas las relaciones del pago ni la comunicación entre las partes. Tampoco combina automáticamente las firmas de distintas entradas, que hacen referencia a salidas recibidas anteriormente y gastadas en esta transacción. [5] [6]

Además de la key path conjunta, Taproot puede incluir condiciones de script, como otra combinación de claves o un bloqueo temporal. Este permite usar una vía solo después de un tiempo o una altura de bloque determinados; no sustituye las firmas necesarias. Un bloque agrupa transacciones en un lote que se añade al historial compartido. La altura de bloque es su posición en la cadena. Las condiciones deben quedar fijadas criptográficamente al crear la salida, una cantidad concreta con reglas de gasto. No pueden añadirse después de perder a un firmante. La script path consiste en gastar mediante ese script: revela las condiciones correspondientes y puede costar más. Recuperar la cartera exige, por tanto, los detalles del esquema elegido, no solo las claves secretas individuales. [6] [1] [9]

BIP327 describe el protocolo, mientras que la biblioteca y la cartera determinan la interfaz, las copias y los procedimientos reales. Revise versión, vectores de prueba, manejo de nonces y revisión de la transacción. Admitir firmas Schnorr no significa que toda cartera tenga soporte completo de MuSig2. La firma conjunta utiliza las reglas existentes de BIP340 y Taproot; MuSig2 no requiere por sí mismo un nuevo opcode de consenso. [4] [7] [2]

Para obtener la imagen más completa, lee esta entrada junto con Schnorr Signature, Taproot, Multisig, PSBT. También enlazan con esta entrada Schnorr Signature, Submarine Swap, FROST, PTLC.

DOC · 001BIP 327 — MuSig2 for BIP340-compatible Multi-SignaturesEspecificación DOC · 002Bitcoin Optech — MuSigDocumentación DOC · 003MuSig2 paperFuente primaria DOC · 004Bitcoin Core — secp256k1 libraryDocumentación DOC · 005BIP 340 — Schnorr SignaturesEspecificación DOC · 006BIP 341 — TaprootEspecificación DOC · 007libsecp256k1 — MuSig2 API and nonce safetyDocumentación DOC · 008Bitcoin Developer Guide — WalletsDocumentación DOC · 009Bitcoin Developer Guide — Block ChainDocumentación DOC · 010Bitcoin Developer Reference — TransactionsDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero