Signet permite probar software de Bitcoin entre varios participantes. Tiene su propia cadena y monedas de prueba. Además de las reglas habituales y Proof of Work, los bloques nuevos deben cumplir una condición especial, basada en una firma en el Signet predeterminado. Esto facilita las pruebas, pero supone un modelo de confianza distinto al de la red principal.
Ana quiere ver qué muestra un monedero nuevo al enviar un pago y cuando este se confirma en un bloque. Un monedero es una aplicación o un dispositivo para recibir y enviar bitcoin. Un bloque agrupa transacciones en un lote que se añade al historial compartido. En Signet Ana puede usar monedas de prueba, por ejemplo de un faucet, un servicio que las distribuye para experimentar. No son BTC de mainnet, la red principal, y el protocolo no los canjea por bitcoins reales. También hay que prestar atención a las direcciones: Signet comparte algunos formatos de prueba con Testnet. Su apariencia no basta para identificar la red correcta. [1] [2] [8]
Karl-Johan Alm y Anthony Towns redactaron BIP 325 (el documento técnico que describe Signet); Bitcoin Core v0.21.0 incorporó Signet. El programa ofrece una red pública predeterminada, pero un equipo puede establecer su propia condición para crear bloques y sus propios participantes. Por eso no basta con decir «usamos Signet»: ambas partes deben estar en la misma red. El identificador de los mensajes de red se deriva de esa condición, no del nombre del proyecto. [1] [3] [4]
Un Full Node, un nodo que comprueba las reglas por sí mismo, sigue verificando las transacciones y Proof of Work, el resultado del trabajo de cálculo necesario para crear un bloque. También comprueba la condición adicional de Signet. En la red predeterminada, minar no basta: hace falta la firma correspondiente. La cabecera, el resumen compacto del bloque, no sustituye esta comprobación; los datos necesarios están dentro del bloque. [1] [9]
Una firma digital permite verificar que el titular de la clave privada correspondiente, un valor numérico secreto, aprobó un mensaje sin revelar esa clave. Quien puede cumplir la condición de firma influye en la creación de bloques. Puede retrasar la firma o limitar las transacciones que incluye. Eso no le entrega las claves privadas de Ana ni le permite obligar a su nodo a aceptar cualquier transacción inválida. Las demás reglas siguen vigentes. Esta participación controlada resulta útil para las pruebas y explica por qué Signet no reproduce el modelo de seguridad de mainnet. [1] [9]
Desarrollar una aplicación requiere más que ver un pago exitoso. El equipo necesita saber qué ocurre si dejan de llegar bloques o hay una reorganización: el nodo sustituye bloques recientes por otra rama válida. Una prueba coordinada puede preparar esa situación y comprobar si el monedero actualiza las confirmaciones correctamente. Signet no promete funcionar sin interrupciones; ayuda a probar los fallos de forma más previsible. [1] [5] [6]
En Testnet la creación de bloques es abierta y sus fluctuaciones pueden complicar un experimento compartido. Regtest permite crearlos fácilmente y a demanda, algo útil en pruebas automáticas propias. También puede conectar varios ordenadores; no tiene por qué ser un programa aislado. Signet responde a otra necesidad: la colaboración prolongada de participantes independientes con condiciones acordadas para crear bloques. Ninguno de estos modos sustituye todas las demás pruebas. [1] [2]
La challenge es un script, un pequeño programa que establece qué debe demostrar un bloque. Puede exigir una firma o Multisig, un número acordado de firmas de varias claves. Un Signet propio también puede usar OP_TRUE, una condición que se cumple sin firma. En ese caso basta una solución vacía. Lo preciso es hablar de una condición adicional de script, no afirmar que cualquier Signet necesita siempre un firmante. [1] [9]
BIP 325 coloca la solución no vacía en datos especiales de la Coinbase Transaction, la primera transacción del bloque. Aquí el nombre no guarda relación con la empresa de intercambio. Los datos amplían el compromiso criptográfico (commitment) de BIP 141, que vincula el bloque con sus datos witness, entre ellos las firmas, y se identifican mediante 0xecc7daa2. No constituyen otro pago ordinario al firmante. Una condición trivialmente satisfacible permite omitir la solución adicional, no prescindir automáticamente de las demás reglas. [1] [9] [10]
Si el mensaje firmado contuviera esa misma firma, habría una dependencia circular. Por eso la verificación usa una huella modificada de las transacciones con la solución vaciada y dos transacciones virtuales. Estas sirven para calcular; no se envían como pagos adicionales. La firma tampoco abarca el nonce de la cabecera, el número que cambia al buscar Proof of Work. Cambiarlo no exige otra firma, pero eso no permite modificar libremente el resto del bloque. [1] [9]
Ana confirma primero que el monedero, el nodo y el explorador de bloques usan la misma red de pruebas. Un explorador de bloques es una aplicación para consultar transacciones y bloques de una red concreta. En Bitcoin Core ayudan getblockchaininfo y su campo signet_challenge, que muestra la condición configurada. Después observa la confirmación real, no solo el aviso de envío, y utiliza un monedero de pruebas separado. El éxito muestra cómo se comporta la aplicación en esas condiciones; no garantiza la seguridad de los fondos ni la resistencia a un atacante en mainnet. [7] [8]
Para obtener la imagen más completa, lee esta entrada junto con Nakamoto Consensus, Block Propagation, Initial Block Download, Block Weight, Bitcoin, Bitcoin Core. También enlazan con esta entrada Testnet, Miniscript, Dead Man’s Switch.