Job Negotiation es el acuerdo entre un minero y un pool sobre un trabajo minero propio. Stratum V2 define las reglas de comunicación entre los equipos de minería y el pool. Job Declaration Protocol es la parte que gestiona las propuestas propias, junto con la distribución de plantillas y tareas. Su objetivo es permitir la selección de transacciones mientras el pool sigue registrando el trabajo y pagando recompensas. Lo decisivo es la configuración real, no solo el nombre de la conexión.
Ana cambia a Stratum V2, pero sigue recibiendo la lista de transacciones del pool. No hay contradicción. Mining Protocol, la parte que transporta trabajo y resultados, puede funcionar sin Job Declaration ni Template Distribution. Esta última entrega plantillas de bloques; Job Declaration gestiona las propuestas propias. Para que Ana elija, esas funciones deben estar presentes y el pool debe admitirlas. Un transporte más moderno, por sí solo, no dice quién decide el contenido de un bloque en la red Bitcoin. [1] [4]
Los pagos seleccionados no pueden llenar tanto el bloque que ya no quepa su transacción de recompensa, coinbase. El proveedor de plantillas, Template Provider, necesita conocer la reserva necesaria. Del lado de Ana funciona el programa JDC, abreviatura de Job Declarator Client. Obtiene los requisitos de los pools utilizados y los envía al proveedor de plantillas en un mensaje de datos llamado CoinbaseOutputConstraints. Se reserva espacio de datos y sigops, las operaciones de verificación de firmas que cuentan para el límite del bloque. De lo contrario, añadir salidas de coinbase, las partidas que asignan fondos, podría superar los límites del bloque. La selección propia debe tener en cuenta desde el principio la validez del resultado completo. [3]
En el modo Full-Template, JDC envía DeclareMiningJob a JDS, el Job Declarator Server del pool o de un servicio en el que este confía. La comunicación contiene los identificadores de las transacciones elegidas. Si al servidor le falta alguna, puede pedir sus datos mediante ProvideMissingTransactions. Ana comparte así información que permite revisar su selección. Confirmar la declaración y aceptar después el trabajo propio en el pool son dos pasos distintos. El primer mensaje satisfactorio no completa todo el acuerdo. [2]
En el modo Coinbase-only, JDC no revela el conjunto de transacciones y no se utiliza DeclareMiningJob. El pool estima los ingresos a partir de la coinbase presentada. Esto oculta la selección de Ana al pool, pero no demuestra por sí mismo que las transacciones ocultas sean válidas ni cuáles sean sus comisiones reales. La especificación señala expresamente ese riesgo. Compartir menos información también cambia lo que se puede comprobar; el nombre del modo no garantiza que estén demostradas todas las condiciones de la recompensa. Esta privacidad se refiere a la propuesta durante la minería. Si Ana encuentra un bloque válido y lo difunde por la red, sus transacciones pasan a ser visibles. [2]
En el intercambio técnico aparecen varias referencias parecidas. JDS asigna mining_job_token, al que el cliente hace referencia en SetCustomMiningJob. Cuando el pool acepta el trabajo, responde con SetCustomMiningJob.Success y su propio job_id. El token y job_id cumplen funciones distintas: el primero enlaza el proceso de propuesta y el segundo identifica el trabajo al entregar resultados. Es parecido al número de solicitud y al número de un encargo aprobado. Confundirlos impediría al pool asociar un resultado con el trabajo aceptado correcto. [1]
Esperar cada intercambio de red retrasaría innecesariamente los equipos. Cuando el cliente tiene el token y la plantilla necesarios, puede comenzar la minería optimista antes de SetCustomMiningJob.Success. Los shares obtenidos, resultados parciales que demuestran trabajo según el objetivo del pool, se guardan hasta la confirmación. Tras aceptarse el trabajo, pueden enviarse con el identificador asignado. Por tanto, una máquina funcionando no demuestra aún que el pool haya aceptado o contabilizado ese trabajo. Empezar a calcular y acordar su remuneración son momentos diferentes. [1] [2]
Si Ana recibe SetCustomMiningJob.Error o no obtiene respuesta en un plazo razonable, la especificación recomienda otro pool o minería en solitario. La resistencia depende de un fallback operativo, una vía alternativa preparada. Si el programa pasara silenciosamente a la plantilla original del pool que la rechazó, podría seguir funcionando, pero perdería la selección de Ana. Importa saber qué hace realmente el sistema ante un rechazo. Que el protocolo describa una capacidad no demuestra que todos los servicios la admitan. [1] [4]
Ana quiere elegir transacciones y conservar las recompensas compartidas. Su JDC debe asignar valor a la salida designada del pool en coinbase para cumplir las condiciones de esas recompensas. Si dirige parte de los ingresos a otro destino, el pool puede reducir proporcionalmente el pago por ese trabajo. Job Declaration no crea un pago directo automático al minero ni elimina las condiciones contables del servicio. Cambia sobre todo quién puede proponer el contenido del bloque; las reglas de validez y el reparto de ingresos deben evaluarse por separado. [2]
Para obtener la imagen más completa, lee esta entrada junto con Stratum V2, getblocktemplate, Mining Pool, Block Template, Bitcoin. También enlazan con esta entrada Stratum V2, Mining Pool Centralization.