134 / 736SCHNORR

Schnorr Signature

Firma Schnorr

Cuando una cartera firma un pago, no crea una imagen de una firma ni envía tu clave privada. Genera una prueba que la red puede verificar. Schnorr Signature permite crear esa prueba de forma compacta y también que varias personas firmen juntas. En Bitcoin se utiliza con Taproot.

Schnorr Signature permite aprobar digitalmente un mensaje concreto sin revelar una clave privada. La cartera utiliza esa clave secreta para crear la firma; los demás solo necesitan la clave pública correspondiente para verificarla. En Bitcoin, la firma ayuda a demostrar la autorización para gastar monedas, pero no sustituye las demás comprobaciones de la transacción. BIP340 define la variante de Bitcoin utilizada con Taproot.

Alice quiere enviar bitcoin a Bob. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Su cartera construye la transacción y firma con la clave privada los datos exigidos por el modo de firma elegido. Después, un nodo verifica la firma y las demás condiciones de gasto. Un nodo es un programa que verifica transacciones y bloques y se comunica con otros participantes de la red. Una firma válida, por sí sola, no acredita la identidad legal de Alice, que el destinatario sea el correcto ni que existan suficientes fondos sin gastar; son cuestiones distintas. Un pago firmado aún puede ser un error involuntario. [5] [3] [10] [11]

BIP340, de Pieter Wuille, Jonas Nick y Tim Ruffing, define con precisión la firma Schnorr de Bitcoin. BIP341 la incorpora a las reglas de gasto de Taproot, activadas en la red principal de Bitcoin (Mainnet) en el bloque 709632, en 2021. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Son dos capas: el algoritmo de firma y las condiciones de gasto. Las salidas antiguas y SegWit v0 siguen utilizando ECDSA, el algoritmo de firma anterior; la actualización no sustituyó sus firmas de forma retroactiva. [1] [2] [11]

El byte es una unidad habitual para medir datos. La variante de Bitcoin utiliza la curva elíptica secp256k1, una estructura matemática para trabajar con claves y firmas. BIP340 establece un formato de firma fijo de 64 bytes. La clave pública se representa mediante los 32 bytes de la coordenada x; x-only no significa omitir una comprobación de seguridad. Las reglas también determinan sin ambigüedad qué variante del punto de la curva debe usar quien verifica. Un formato más pequeño y preciso facilita el trabajo del software, pero esas dos cifras no bastan para conocer el tamaño de una transacción completa. [1] [12]

La cartera no firma un «estoy de acuerdo» impreciso. El modo sighash determina qué datos de la transacción forman el mensaje firmado. SIGHASH_DEFAULT protege información sobre todas las entradas y salidas, de forma similar a SIGHASH_ALL: qué monedas recibidas antes se gastan y qué nuevos importes con condiciones de gasto se crean. Cambiar datos cubiertos invalida la firma. Eso no significa firmar cada byte, por ejemplo las otras firmas. Otros modos permitidos protegen un alcance distinto. La firma ocupa 64 bytes; un modo no predeterminado añade un byte de tipo, por lo que ese elemento ocupa 65 bytes. Sigue sin ser el tamaño de la entrada o de la transacción completa. [2]

Al firmar se genera un valor secreto llamado nonce. Reutilizarlo para mensajes distintos con la misma clave puede revelar la clave privada. Por eso BIP340 precisa cómo se deriva y recomienda datos aleatorios auxiliares para proteger la implementación. El usuario no inventa el nonce ni lo apunta en su copia de seguridad. Lo gestiona una biblioteca de firmas contrastada; improvisar aquí puede arruinar una criptografía que, por lo demás, es correcta. [1] [9]

La estructura matemática de las firmas Schnorr permite protocolos en los que varias personas acuerdan un mensaje y producen una firma conjunta. MuSig2, definido en BIP327, es un ejemplo. En la forma básica de este protocolo, todos los miembros del grupo elegido deben contribuir. Requiere coordinación, gestión correcta de las claves y su propio procedimiento seguro para los nonce. No basta con sumar firmas cualesquiera ya terminadas. Que una cartera admita Schnorr Signature tampoco significa, por sí solo, que permita esa colaboración. [8]

Taproot ofrece distintas vías de gasto. En la key path, la red verifica una firma frente a la clave pública fijada en la salida. Detrás puede haber una persona o un grupo que coopera. En la script path se revela el script elegido: un programa con condiciones que el pago debe cumplir. Tapscript es la versión de ese lenguaje utilizada por Taproot. Su instrucción OP_CHECKSIGADD verifica una firma y, si es válida, suma uno a un contador. Repitiéndola se pueden evaluar varias firmas independientes y comprobar el número exigido. Este Multisig mediante scripts es distinto de una firma agregada. En cada cartera, revisa quién debe colaborar, qué se publica y qué recuperación sigue siendo posible si se pierde una clave. [7] [2]

En una red sin árbitro central, un nodo no debe aceptar una firma que otro rechaza por interpretar sus bytes de manera distinta. BIP340 define por ello las claves válidas, las firmas y el procedimiento de verificación con detalle. También permite batch verification: verificar varias firmas juntas para ahorrar cálculo. Esto no reescribe sus registros en la cadena ni combina firmas de entradas distintas de una transacción. [1]

Una firma conjunta por key-path puede parecer la firma de una sola clave. Por tanto, la firma por sí misma no tiene por qué revelar cuántas personas se pusieron de acuerdo. Sin embargo, los importes, las conexiones entre entradas y salidas y el momento de la transacción suelen seguir siendo observables. Schnorr Signature no cifra el pago. La privacidad también depende del uso de Taproot, del comportamiento de la cartera y de las circunstancias del pago. [2] [3]

Para el usuario importa una cartera que muestre correctamente el destinatario, el importe y la comisión y permita una recuperación fiable. El desarrollador debe comprobar además la compatibilidad exacta con BIP340, los vectores de prueba, la gestión de nonce y el comportamiento ante errores. El nombre del algoritmo no garantiza todo el producto. Una buena biblioteca, como libsecp256k1, realiza el cálculo criptográfico; no decide si la persona debe autorizar el pago mostrado. [4] [9] [6]

Para obtener la imagen más completa, lee esta entrada junto con Taproot, MuSig2, Multisig, Bitcoin Script. También enlazan con esta entrada SHA-256, Opcode, MuSig2, Nostr.

DOC · 001BIP 340 — Schnorr SignaturesEspecificación DOC · 002BIP 341 — TaprootEspecificación DOC · 003Bitcoin Optech — Schnorr signaturesDocumentación DOC · 004Bitcoin Core — secp256k1 verificationDocumentación DOC · 005Bitcoin Core — Script interpreterDocumentación DOC · 006BIP 340 rendered specificationEspecificación DOC · 007BIP342 — Validation of Taproot ScriptsEspecificación DOC · 008BIP327 — MuSig2Especificación DOC · 009libsecp256k1 — Schnorr signature APIDocumentación DOC · 010Bitcoin Developer Guide — WalletsDocumentación DOC · 011Bitcoin Developer Guide — Block ChainDocumentación DOC · 012Bitcoin Developer Reference — TransactionsDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero