228 / 691GBT

getblocktemplate

Interface do nó para obter um modelo de mineração

getblocktemplate separa obtenção de dados, verificação prévia de propostas e envio do bloco. O cliente deve entender regras, identificadores de transações e respostas do nó; uma chamada RPC bem-sucedida não minera nada por si só.

getblocktemplate é um método JSON-RPC para obter dados de montagem de um bloco candidato ou avaliar uma proposta. Esta descrição segue Bitcoin Core 29; o comportamento de uma implementação não se aplica automaticamente a todos os servidores do protocolo.

O mode padrão é template. A resposta fornece dados ao software de mineração, não um proof of work encontrado. Essa solicitação não recebe endereço de pagamento como parâmetro; montar a coinbase e procurar uma solução são etapas posteriores. [Bitcoin Core 29 — getblocktemplate RPC]

Bitcoin Core v29.0 exige segwit nas rules solicitadas, e signet na rede signet. Escrever uma string não substitui implementar as regras correspondentes. capabilities descreve funções da interface e não substitui as rules obrigatórias. [Bitcoin Core v29.0 — Mining RPC implementation]

BIP 145 distingue txid sem witness de hash com witness. A Merkle root principal usa txid, não o hash witness. data contém a transação serializada em hexadecimal; seu identificador sozinho não contém todos os bytes. [BIP 145 — SegWit template fields]

O cliente devolve o longpollid recebido na próxima solicitação de espera. BIP 22 orienta não supor um significado específico; um cliente portátil não deve interpretá-lo como um formato próprio. Long polling precisa de timeout longo e pausas após falhas repetidas, não de um ciclo imediato de tentativas. [BIP 22 — Long polling]

Bitcoin Core v29.0 mantém o modelo em cache: ele muda quando muda o predecessor, ou quando o mempool muda mais de cinco segundos após sua criação. O tempo do cabeçalho é atualizado separadamente. Cada chamada não precisa incluir a transação mais recente nem criar trabalho de mineração independente. [Bitcoin Core v29.0 — Mining RPC implementation]

No modo proposal, data contém o bloco candidato inteiro em hexadecimal. Core verifica a Merkle root, mas não exige proof of work válido. inconclusive-not-best-prevblk significa que o predecessor difere da ponta atual; não é uma avaliação completa da validade da proposta. [Bitcoin Core v29.0 — Mining RPC implementation]

submitblock recebe o bloco completo como hexdata, não apenas um hash. Bitcoin Core 29 retorna null ao aceitar; caso contrário pode retornar uma string de resultado. O dummy opcional é ignorado. A aceitação pelo nó não garante confirmação permanente na cadeia ativa. [Bitcoin Core 29 — submitblock RPC]

Na mainnet, Bitcoin Core v29.0 não fornece modelo sem peers conectados ou durante initial block download. Isso descreve a prontidão do nó, não a invalidade de um bloco específico. Distinga esses erros de motivos de rejeição na validação e de long polling aguardando normalmente. [Bitcoin Core v29.0 — Mining RPC implementation]

Para ter uma visão mais completa, leia este verbete junto com Block Template, Mineração, Stratum V2, Extranonce. Também há referências a este verbete em ASIC Miner, Solo Mining, Job Negotiation.

DOC · 001Bitcoin Core 29 — getblocktemplate RPCDocumentação ↗DOC · 002Bitcoin Core v29.0 — Mining RPC implementationFonte primária ↗DOC · 003BIP 145 — SegWit template fieldsEspecificação ↗DOC · 004BIP 22 — Long pollingEspecificação ↗DOC · 005Bitcoin Core 29 — submitblock RPCDocumentação ↗
Fontes em primeiro lugar · Não é recomendação de investimento