Block Template

Cada novo bloco se apoia em um antecessor específico. O modelo o identifica por previousblockhash, sua impressão digital única, enquanto height indica a posição do bloco proposto na cadeia. Outros campos incluem version, a versão do cabeçalho; bits, uma representação compacta do alvo para o resultado da mineração; e informações de tempo. São dados para montar um bloco determinado, não uma lista independente de pagamentos. As mesmas transações depois de outro antecessor já formam uma tarefa diferente. [1]

Anna recebe bitcoin e depois paga com ele. Se as duas transferências forem incluídas no mesmo bloco, a transação que lhe atribuiu os fundos precisa vir antes daquela que os gasta. BIP 22, o documento técnico que descreve o formato do modelo, define o campo depends para essas relações: o campo aponta para entradas anteriores da lista transactions, com posições numeradas a partir de um. A lista exclui coinbase, a primeira transação especial que atribui a recompensa ao minerador. A ausência de depends significa dependências desconhecidas, não a confirmação de que elas não existem. O software não deve tratar informação ausente como lista vazia. [1]

A recompensa inclui os bitcoins recém-emitidos segundo as regras daquela altura e as taxas das transações realmente incluídas. A versão citada, Bitcoin Core v29.0, também a calcula assim. Esse programa verifica blocos e transações e também pode preparar modelos para mineração. Em nosso exemplo, as transações rendem 10000 sats; retirar uma transação independente que paga 3000 sats deixa 7000 sats em taxas. Sats são pequenas unidades de bitcoin. O campo coinbasevalue indica a recompensa máxima que o minerador pode atribuir a si com a seleção original de transações. Se essa seleção mudar, é preciso recalcular o valor. O cálculo precisa usar as taxas reais, não um total feito para o conteúdo antigo. [4] [1]

Um bloco também contém impressões digitais criptográficas para conferir seus dados. BIP 141 descreve o witness commitment, uma impressão digital criptográfica que vincula o bloco aos dados witness, que incluem, por exemplo, assinaturas demonstrando autorização para gastar. Esse commitment é derivado dos identificadores wtxid que abrangem esses dados. Bitcoin Core 29 fornece default_witness_commitment para um modelo inalterado. Após mudanças nas transações pertinentes ou na ordem delas, é preciso conferir ou recalcular essa impressão digital. A Merkle root, a impressão digital conjunta das transações no cabeçalho, também precisa ser calculada a partir dos identificadores TXID finais, incluindo o da coinbase alterada. Um selo antigo não serve para um conteúdo modificado. [5] [3]

O espaço do bloco é limitado, e o minerador escolhe o que incluir. Bitcoin Core v29.0 avalia pacotes de transações relacionadas, seu peso, uma medida de carga de dados, e sigops, as operações de verificação de assinaturas contabilizadas para o limite do bloco. Configurações como blockmaxweight e blockmintxfee influenciam o tamanho do bloco montado e a taxa por unidade de espaço exigida. Isso é política de seleção. Um pagamento omitido por esse motivo não é necessariamente inválido pelas regras da rede. A configuração do minerador também não aumenta os limites de rede verificados pelos outros nós. [4] [3]

Em BIP 23, mutable lista as alterações permitidas pelo servidor, como ajustar o tempo ou acrescentar transações. É um acordo sobre o uso de um modelo específico. A permissão não anula o consenso, isto é, as regras de validade que outros participantes verificam de forma independente. Antecessor, tempo, dificuldade e transações continuam tendo de estar corretos. Acesso ao modelo também não significa que todo equipamento conectado possa mudar seu conteúdo livremente; isso depende da organização do sistema e da tarefa recebida. [2]

Outro minerador pode ampliar a cadeia enquanto os cálculos continuam. Para trabalhar sobre o último bloco aceito, não basta trocar a impressão digital do antecessor no modelo antigo. Algumas transações talvez já estejam confirmadas, e mudam a altura e outras condições. BIP 23 descreve expires como um prazo de validade do trabalho e prevblock como permissão para usá-lo com outro antecessor. Mesmo essa permissão não substitui a validação: é necessário reavaliar transações, recompensa e todo o novo contexto. [2]

É melhor descobrir um erro no rascunho antes de uma busca demorada. O modo proposal de BIP 23 permite apresentá-lo para avaliação sem exigir uma Proof of Work válida, ou seja, um resultado já encontrado que comprove o trabalho computacional necessário. Uma avaliação positiva não significa que um bloco foi encontrado ou transmitido, nem garante seu lugar permanente na cadeia. Significa que o rascunho passou pela verificação preliminar correspondente. Ao ser enviado, o bloco concluído ainda precisa passar pela validação adequada, incluindo a prova de trabalho. [2]