getblocktemplate

No modo habitual mode=template, o programa de Pedro recebe, por exemplo, o bloco anterior, as transações e a recompensa permitida. É uma proposta de trabalho, não um bloco já encontrado. O software precisa construir coinbase, a primeira transação especial que atribui a recompensa, e terminar a montagem do bloco. O cabeçalho reúne um resumo compacto dos dados do bloco. Depois, o programa procura um hash, uma impressão digital criptográfica numérica desse cabeçalho, que satisfaça o alvo da mineração e constitua Proof of Work, a prova do trabalho computacional. getblocktemplate não recebe um endereço de pagamento nem inicia os cálculos da máquina. Uma resposta bem-sucedida ainda não significa que Pedro esteja minerando. [1]

Imagine que o nó envie dados num formato que o programa de Pedro não compreenda. Por isso, o pedido declara as regras aceitas no campo rules. Bitcoin Core v29.0, a versão verificada aqui, exige segwit e, para a rede de testes Signet, também signet. SegWit muda, entre outras coisas, o tratamento dos dados de verificação das transações. Acrescentar a palavra certa não basta: o programa precisa saber processá-los. capabilities anuncia outras funções da interface e não substitui rules. Os requisitos exatos dependem da implementação e da versão utilizadas. [2]

O campo data contém a transação completa organizada para transmissão entre programas. Essa organização se chama serialização. Os bytes, as unidades básicas desses dados, são escritos em hexadecimal com os dígitos 0–9 e as letras a–f. A resposta também inclui identificadores curtos das transações. Segundo o documento técnico BIP 145, txid é calculado sem os dados witness, enquanto hash os inclui. Witness contém, por exemplo, assinaturas que comprovam a autorização para gastar. A Merkle root principal, a impressão digital conjunta das transações no cabeçalho do bloco, usa txid, e não witness hash. Confundir esses campos vai além de trocar um nome: pode produzir uma impressão conjunta incorreta e invalidar o bloco montado. [3]

Pedro não precisa bombardear o nó perguntando se algo mudou. Long polling mantém um pedido aberto até o servidor querer substituir os dados anteriores. O programa recebe longpollid e o devolve sem alterações. Esse valor indica ao servidor qual atualização o programa está aguardando. O programa não deve tentar deduzir um significado dos caracteres desse valor. BIP 22 prevê um prazo longo de espera. Respostas incompletas ou inválidas repetidas exigem intervalos entre as tentativas, em vez de um ciclo de repetições imediatas. Por isso, esperar em silêncio não é, por si só, uma falha. [4]

Mesmo repetir um pedido comum não garante conteúdo recém-selecionado. Bitcoin Core v29.0 mantém um modelo preparado em cache. Ele o reconstrói quando o bloco anterior muda, ou quando o mempool, o conjunto local de transações não confirmadas, mudou e passaram mais de cinco segundos desde a preparação. O horário do cabeçalho pode ser atualizado separadamente. Pedro pode, portanto, receber a mesma seleção de transações outra vez; isso não significa que o nó travou. Esse comportamento de uma versão específica também não promete um trabalho de mineração único a cada chamada. [2]

Pedro alterou a montagem do bloco e quer descobrir erros antes de uma busca custosa. No modo proposal, entrega o bloco completo em hexadecimal no campo data. Bitcoin Core v29.0 também verifica a Merkle root, mas não exige que já tenha sido encontrado um Proof of Work válido, a prova do trabalho computacional. Se a proposta não continuar o último bloco da cadeia que o nó está seguindo, a resposta é inconclusive-not-best-prevblk. Falta uma condição necessária para essa verificação; não é uma avaliação completa da validade. A verificação prévia também não transmite o bloco pela rede. [2]

Quando o programa encontra a prova de trabalho necessária, pode enviar o bloco completo por submitblock. hexdata leva todo o bloco serializado em hexadecimal, não apenas o cabeçalho ou a impressão digital. A documentação de Bitcoin Core 29 indica null quando há aceitação e, nos demais casos, um resultado de texto conforme a especificação. O segundo parâmetro opcional, dummy, é ignorado; ele não define a recompensa. A aceitação por um nó não garante confirmação permanente: a evolução posterior da cadeia pode mudar qual ramo permanece como principal. [5]

Um nó recém-iniciado pode ainda não ter baixado e verificado o histórico necessário. Na rede principal, mainnet, Bitcoin Core v29.0 recusa fornecer um modelo sem pares conectados ou durante a sincronização inicial IBD (initial block download). Isso diz respeito à preparação do nó para trabalhar com a rede atual, não à rejeição de um bloco específico. Ao investigar um problema, é preciso distinguir um long poll em espera, um nó ainda não preparado e o resultado da verificação de uma proposta. Todos podem parecer “não tenho trabalho novo”, mas pedem respostas diferentes. [2]