Un mensaje firmado de Bitcoin prueba menos de lo que parece

La respuesta corta

Un mensaje firmado de Bitcoin es evidencia de que alguien pudo satisfacer la condición de gasto detrás de una dirección para un texto específico. Puede vincular una declaración con una clave o un script sin mover bitcoin.

Es evidencia útil, pero las palabras importan. No identifica a la persona que tiene la clave. No prueba que siga controlándola más tarde. No prueba que le pertenezcan todas las monedas asociadas con una wallet. Una firma responde una pregunta criptográfica limitada, no todas las preguntas del mundo real que suelen meterse dentro de la palabra propiedad.

Cómo funciona en realidad

La convención antigua para firmar mensajes creció alrededor de las direcciones heredadas pay-to-public-key-hash, las que empiezan con 1. Firma un hash del mensaje con un formato especial y usa una firma ECDSA recuperable para que quien verifica pueda recuperar una clave pública y comparar su dirección. BIP 137 documenta extensiones usadas por algunas wallets, pero el formato depende de los tipos de dirección y no ofrece un modelo común de verificación para scripts arbitrarios de Bitcoin.

BIP 322 adopta otro enfoque. La especificación, revisada el 22 de septiembre de 2026, está completa en su versión 2.0.0. En lugar de inventar una regla de firma separada para cada forma de dirección, construye dos transacciones virtuales y pregunta si se puede satisfacer el script normal de la dirección.

La primera transacción virtual se llama to_spend. Su entrada apunta a una salida que no existe, así que no puede ser un gasto real en Bitcoin. Su script se compromete con un hash etiquetado del mensaje exacto. Su salida de valor cero contiene el script detrás de la dirección que se está comprobando.

La segunda se llama to_sign. Gasta la salida virtual y envía cero a OP_RETURN. Quien firma satisface su entrada como si estuviera gastando el script de la dirección. Quien verifica reconstruye la primera transacción a partir del mensaje y la dirección, comprueba que la segunda la gasta y luego ejecuta las reglas aplicables de Bitcoin Script.

El hash del mensaje usa la etiqueta BIP0322-signed-message. El hash etiquetado separa este uso de otros protocolos que también procesan texto. La forma de transacción virtual separa la prueba de un pago real: la salida previa inexistente impide que el par pueda transmitirse para tomar monedas.

BIP 322 define varias codificaciones:

• smp es la forma simple y compacta. Lleva una pila witness y se aplica a los scripts SegWit nativos cubiertos por la especificación, incluidos P2WPKH y los casos admitidos de P2WSH y Taproot sin timelocks.
• ful lleva la transacción to_sign completa y firmada. Puede representar más tipos de script e incluir condiciones de locktime o sequence.
• pof lleva una transacción de Bitcoin parcialmente firmada finalizada y puede añadir salidas no gastadas reales como entradas para una declaración de fondos.
• La forma heredada permanece por compatibilidad con direcciones P2PKH, pero la especificación recomienda el formato nuevo para pruebas nuevas.

Esos prefijos de tres letras importan. La versión 2.0 hizo explícito el formato elegido. Un verificador puede interpretar un valor antiguo sin prefijo como la forma simple por compatibilidad, pero el software nuevo no debería obligar al lector a adivinar qué reglas produjeron una cadena.

La verificación también tiene más respuestas que sí o no. Puede informar que la prueba es válida con un locktime y una antigüedad de sequence determinados, que no es válida o que es inconclusa porque no entiende el script. Tratar inconclusive como valid convertiría reglas no admitidas en una ruta de aceptación.

Por qué importa

El modelo de transacciones permite que la firma de mensajes siga el modelo de scripts de Bitcoin. Una dirección SegWit nativa, una dirección Taproot o una política multifirma no deberían necesitar convenciones de firma sin relación entre sí solo porque sus cadenas visibles sean diferentes. El mismo intérprete que responde si una salida podría gastarse puede responder si se satisfizo su desafío de mensaje.

Esto importa especialmente en una multifirma. Puede no existir una sola clave pública cuya firma represente toda la política. Un script de dos de tres se satisface con la combinación necesaria de firmantes, no recuperando una clave de una firma. La ruta basada en PSBT también ofrece a los firmantes separados un contenedor conocido para coordinar firmas parciales.

La prueba de fondos añade una segunda pregunta: ¿puede quien firma satisfacer los scripts de un conjunto declarado de salidas de transacciones no gastadas? Quien verifica debe consultar el conjunto UTXO actual para saber si esas salidas todavía existen y siguen sin gastarse. Una comprobación sin conexión puede validar sus scripts, pero no puede establecer su estado actual en la cadena.

Las implementaciones siguen importando. Que un formato esté marcado como completo no promete que todas las wallets, dispositivos de firma, herramientas de línea de comandos o sitios web admitan cada variante. La interfaz tradicional signmessage y verifymessage de Bitcoin Core usa el modelo heredado, mientras que el BIP enumera trabajo de implementación separado para el formato genérico. Antes de depender de una prueba, hay que comprobar que ambos extremos admiten la misma versión de BIP 322 y el mismo prefijo. Nunca se debe pegar la seed o la clave privada de una wallet valiosa en un sitio de firma para resolver una incompatibilidad.

Lo que suele entenderse mal

"La firma prueba quién escribió el mensaje." Prueba acceso a una ruta de firma, no una identidad civil. Si dos personas pueden usar la misma wallet, cualquiera puede producir la prueba. Un custodio también puede firmar por una dirección asociada con un cliente. La identidad exige evidencia separada que vincule a la persona con la dirección y el mensaje exacto.

"La firma prueba propiedad permanente." Una prueba válida describe un momento. La clave puede perderse, rotarse, compartirse o quedar comprometida después. BIP 322 puede expresar condiciones de tiempo, pero no puede prometer control futuro.

"Una prueba de fondos muestra el saldo completo." Quien firma elige qué salidas incluir. El formato no prueba que no existan otras salidas y no convierte un conjunto de direcciones en un inventario completo de la wallet. Tampoco puede probar que el firmante aceptaría gastar esas salidas para quien verifica.

"Firmar es lo mismo que enviar una transacción." No se mueven monedas. La entrada virtual no existe en Bitcoin y la salida es un OP_RETURN de valor cero. La construcción toma prestadas las reglas de validación de transacciones sin crear un pago válido para la red.

"Cualquier resultado exitoso es intercambiable." Los valores heredados, simples, completos y de prueba de fondos tienen capacidades y codificaciones diferentes. La dirección, el mensaje exacto, el prefijo de la firma, la versión del software y el resultado de verificación deben guardarse juntos. Un resultado copiado sin ese contexto es difícil de auditar después.

Dónde seguir

Conviene leer BIP 322 junto con los fundamentos de criptografía asimétrica si no está clara la diferencia entre firmar y cifrar. Para una implementación, se deben usar los vectores de prueba publicados por la especificación en lugar de inventar un ejemplo. Cubren el hash etiquetado del mensaje, los identificadores de las transacciones virtuales y las firmas simples.

En una solicitud real de verificación, el mensaje debe ser específico: hay que incluir el propósito, la fecha, la contraparte y un nonce que no se reutilice. La dirección y la firma deben guardarse con el mensaje UTF-8 exacto. La conclusión también debe ser limitada: el script se satisfizo para ese mensaje bajo esas reglas de verificación. Esa frase es menos dramática que "propiedad probada" y mucho más precisa.