Job Negotiation é o acordo entre minerador e pool sobre uma tarefa de mineração própria. Stratum V2 define as regras de comunicação entre os equipamentos de mineração e o pool. Job Declaration Protocol é a parte que cuida das propostas próprias, em conjunto com a distribuição de modelos e tarefas. A finalidade é permitir a seleção de transações enquanto o pool continua registrando o trabalho e pagando recompensas. O que importa é a configuração real, não apenas o nome da conexão.
Ana muda para Stratum V2, mas continua recebendo a lista de transações do pool. Não há contradição. Mining Protocol, a parte que transporta trabalho e resultados, pode funcionar sem Job Declaration e Template Distribution. Esta última fornece modelos de blocos; Job Declaration trata das propostas próprias. Para Ana escolher, essas funções também precisam estar presentes, junto com um pool que as aceite. Um transporte mais moderno, por si só, não diz quem determina o conteúdo de um bloco na rede Bitcoin. [1] [4]
Os pagamentos escolhidos não podem preencher tanto o bloco que sua transação de recompensa, coinbase, fique sem espaço. O provedor do modelo, Template Provider, precisa conhecer a reserva necessária. Do lado de Ana funciona o programa JDC, abreviação de Job Declarator Client. Ele obtém os requisitos dos pools usados e os envia ao provedor do modelo numa mensagem de dados chamada CoinbaseOutputConstraints. Reservam-se espaço de dados e sigops, as operações de verificação de assinaturas contabilizadas no limite do bloco. Caso contrário, acrescentar saídas coinbase, os registros que atribuem fundos, poderia ultrapassar os limites do bloco. A escolha própria precisa considerar desde o início a validade do resultado inteiro. [3]
No modo Full-Template, JDC envia DeclareMiningJob a JDS, o Job Declarator Server do lado do pool ou de um serviço no qual ele confia. A mensagem informa os identificadores das transações escolhidas. Se alguma faltar ao servidor, ele pode pedir seus dados por ProvideMissingTransactions. Ana compartilha, portanto, informações que permitem conferir sua seleção. Confirmar a declaração e o pool aceitar depois a tarefa própria são duas etapas separadas. A primeira mensagem de sucesso ainda não conclui todo o acordo. [2]
No modo Coinbase-only, JDC não revela o conjunto de transações e DeclareMiningJob não é usado. O pool estima a receita pela coinbase apresentada. Isso esconde a seleção de Ana do pool, mas não prova por si só a validade das transações ocultas nem suas taxas reais. A especificação descreve expressamente esse risco. Compartilhar menos dados também muda o que se pode conferir; o nome do modo não garante que todas as condições de recompensa estejam devidamente demonstradas. Essa privacidade se refere à proposta durante a mineração. Se Ana encontrar um bloco válido e o divulgar na rede, suas transações ficarão visíveis. [2]
Várias referências parecidas aparecem na comunicação técnica. JDS atribui mining_job_token, citado pelo cliente em SetCustomMiningJob. Quando aceita a tarefa, o pool responde com SetCustomMiningJob.Success e seu próprio job_id. O token liga as etapas da proposta; job_id identifica o trabalho ao enviar resultados. É parecido com um número de solicitação e o número de uma ordem de serviço aprovada. Confundi-los impediria o pool de associar um resultado à tarefa aceita correta. [1]
Esperar cada troca de mensagens atrasaria os equipamentos sem necessidade. Quando o cliente tem o token e o modelo necessários, pode começar a mineração otimista antes de SetCustomMiningJob.Success. Os shares encontrados, resultados parciais que demonstram trabalho conforme o alvo do pool, ficam guardados até a confirmação. Depois da aceitação da tarefa, podem ser enviados com a identificação atribuída. Uma máquina funcionando ainda não prova que o pool aceitou ou contabilizou aquele trabalho. Começar a calcular e concordar em remunerar a tarefa são momentos diferentes. [1] [2]
Se Ana recebe SetCustomMiningJob.Error ou não obtém resposta num prazo razoável, a especificação recomenda outro pool ou mineração solo. A resistência depende de um fallback funcional, um caminho alternativo preparado. Se o software mudasse silenciosamente para o modelo original do pool que recusou a proposta, poderia continuar funcionando, mas perderia a escolha de Ana. Importa saber o que o sistema realmente faz diante da recusa. Uma capacidade descrita no protocolo não prova que todos os serviços a ofereçam. [1] [4]
Ana quer escolher transações e manter as recompensas compartilhadas. Seu JDC precisa, portanto, atribuir valor à saída coinbase indicada pelo pool para cumprir as condições dessas recompensas. Se direcionar parte da receita para outro destino, o pool pode reduzir proporcionalmente o pagamento por esse trabalho. Job Declaration não cria um pagamento direto automático ao minerador nem elimina as condições contábeis do serviço. Ele muda principalmente quem pode propor o conteúdo do bloco; as regras de validade e a divisão da receita precisam ser avaliadas separadamente. [2]
Para ter uma visão mais completa, leia este verbete junto com Stratum V2, getblocktemplate, Mining Pool, Block Template, Bitcoin. Também há referências a este verbete em Stratum V2, Mining Pool Centralization.