Mining Target

Imagine, apenas como ilustração, um limite de 20: resultados de 19 e 20 serviriam, mas 21 não. Na mineração real, os números são muito maiores, mas a relação é a mesma: hash ≤ target. O símbolo significa menor ou igual, não estritamente menor. Bitcoin Core é um programa usado pelos participantes da rede para verificar blocos e transações. A versão v29.0 citada aqui compara assim o hash do cabeçalho inteiro. O nonce, valor que o minerador altera durante a busca, é um dos dados de entrada. O que se compara com o alvo é o hash resultante. [1]

Jana vê uma imagem de um hash bem-sucedido começando com muitos zeros. É uma boa ilustração: em representações de mesmo comprimento, mais zeros iniciais significam um número menor. Mas dois hashes com a mesma quantidade de zeros podem ficar em lados diferentes do alvo. Os demais dígitos também importam. Os zeros não substituem a comparação completa hash ≤ target. A regra exige uma condição numérica exata, não um desenho bonito de caracteres. [1]

Um bit pode assumir o valor zero ou o valor um; oito bits formam um byte. Para não armazenar o número longo inteiro no cabeçalho, Bitcoin usa o campo nBits de 32 bits. Ele codifica um alvo no espaço dos números de 256 bits usando um coeficiente, um expoente que determina o deslocamento e um bit de sinal. Por exemplo, 0x04123456 é decodificado como 0x12345600; o prefixo 0x indica notação hexadecimal, que também usa letras. É um exemplo de codificação, não o alvo atual da rede. Para entender o básico, basta distinguir o número de sua representação abreviada. [3] [5]

Nos dados brutos, o mesmo número pode parecer invertido. No cabeçalho de 80 bytes, nBits ocupa quatro bytes armazenados em little-endian: o byte menos significativo vem primeiro. Por isso, o número 0x1d00ffff aparece nos dados como ff ff 00 1d. A ordem dos bytes não muda o alvo; descreve apenas o armazenamento. Esse detalhe importa ao trabalhar com dados brutos. Quem consulta normalmente um explorador de blocos não precisa inverter os números na tela. [2]

Jana poderia sugerir armazenar um número maior para facilitar a busca. Mas o software verifica mais do que a capacidade de ler nBits. DeriveTarget em Bitcoin Core v29.0 rejeita um alvo negativo, zero, estouro do intervalo numérico e valores acima de powLimit, o maior alvo permitido naquela rede. Decodificar corretamente, portanto, só esclarece qual número a escrita representa; não dá, por si só, autorização para usá-lo. [1]

Mesmo um alvo dentro do intervalo permitido pode estar errado para um bloco específico. Bitcoin Core compara nBits com GetNextWorkRequired, um cálculo baseado no bloco anterior e nas regras da rede. Uma divergência produz bad-diffbits. Um hash baixo sob um alvo próprio mais fácil não justifica um valor incorreto no cabeçalho. Jana não consegue um bloco aceito apenas reduzindo a exigência: os outros nós, computadores que verificam as regras, rejeitam essa tentativa. [4]

Em um modelo de hashes de 256 bits uniformemente distribuídos, cada resultado possível tem a mesma probabilidade. Para um alvo permitido T, são aceitos os valores de zero até T, inclusive. Daí vem p = (T + 1) / 2^256 por tentativa; p representa a probabilidade de sucesso. O um acrescentado inclui o zero. Essa relação explica por que um alvo menor dificulta a busca. Não informa quantas tentativas a máquina faz por segundo nem quando chegará exatamente o próximo bloco. [1]

Ao cumprir a condição, Jana demonstra o trabalho computacional exigido, não a correção de tudo dentro do bloco. Bitcoin Core também verifica a impressão digital conjunta das transações, a transação especial de recompensa chamada coinbase, os limites do bloco e a validade das transações. Aqui, coinbase é o nome técnico da primeira transação do bloco, não da corretora. Um hash baixo não corrige conteúdo inválido. O alvo é uma parte importante das regras, não uma licença para ignorar as demais. [4]