Mining Share

A máquina de Petr faz uma quantidade enorme de tentativas. O pool não precisa receber uma mensagem para cada uma: recebe resultados selecionados que satisfazem uma condição previamente definida. Ele os verifica e estima estatisticamente o trabalho por sua frequência e dificuldade. Uma Mining Share não é parte de um bloco inacabado nem uma participação transferível em bitcoin. Também não é uma transação registrada na blockchain, o histórico público de transações de Bitcoin organizado em blocos interligados. É uma forma de o minerador demonstrar ao pool sua contribuição computacional. [1]

A mineração procura um hash, um resultado de cálculo interpretado como número, que não ultrapasse um alvo definido. O pool normalmente estabelece um alvo numericamente maior que o da rede: mais resultados passam, tornando a condição mais fácil. O que basta para o pool normalmente não basta para um bloco. Por acaso, alguns resultados também satisfazem o alvo mais rigoroso da rede. Podem originar um bloco novo se ele cumprir as demais regras. O pool não afrouxa as regras do Bitcoin; define seu próprio limite para comprovar trabalho continuamente. [1]

Petr não precisa montar essas mensagens manualmente; o software faz isso. Stratum V2 é um protocolo, um conjunto de regras de comunicação entre equipamentos e pool. A mensagem SubmitSharesStandard contém job_id para identificar a tarefa, nonce como valor alterado durante a busca, ntime para a marca de tempo do cabeçalho do bloco e version para a versão do cabeçalho, a parte compacta de dados do bloco. Ela também identifica o canal de comunicação. O pool precisa desse contexto para verificar o cálculo: um nonce sem a tarefa correta não é uma prova independente de trabalho. [2]

Imagine Petr comparando máquinas com tarefas de dificuldades diferentes. A dificuldade funciona aqui como peso: um resultado que atende a uma condição mais rigorosa é contabilizado como mais trabalho. Convertendo os resultados para a mesma escala, dois envios aceitos de dificuldade 1024 têm o mesmo peso total que um de dificuldade 2048. A quantidade de mensagens difere, mas o peso contabilizado do trabalho é igual. Nem essa soma registra exatamente todos os cálculos realizados: os acertos individuais são aleatórios. Por isso, verifique se o contador chamado shares mostra resultados aceitos ou seu peso convertido para uma escala comum. [3]

Às vezes o pool confirma vários envios de uma só vez. Stratum V2 utiliza a resposta SubmitShares.Success. O campo new_submits_accepted_count conta os envios recém-confirmados, enquanto new_shares_sum soma as dificuldades de suas tarefas. O primeiro conta resultados; o segundo, o peso deles. Ambos se referem ao lote confirmado naquele momento, não automaticamente aos totais de toda a atividade do minerador. Ao ler o protocolo, não é necessário esperar uma confirmação separada para cada resultado enviado. [2]

A máquina de Petr pode informar que enviou um resultado enquanto o pool ainda o valida. Stratum V2 usa SubmitShares.Error para um envio incorreto; sequence_number identifica o envio ao qual o erro se refere. Se a validação não puder ocorrer imediatamente, a resposta de erro pode chegar depois. Separe os resultados enviados dos confirmados como aceitos e acompanhe as rejeições. O crescimento do contador local de envios não prova que o pool contabilizou tudo. [2]

O trabalho confirmado entra nas regras de remuneração de cada pool. Por exemplo, FPPS, Full Pay Per Share, na Braiins calcula a recompensa com o trabalho enviado e dados da rede, incluindo dificuldade e recompensas de blocos; também inclui uma parcela de taxas de transação. O pool desconta sua taxa, e as transferências seguem as configurações de pagamento. Confirmar uma share não envia BTC (bitcoins) à carteira por si só. Petr acompanha separadamente trabalho aceito, recompensa calculada e pagamento efetivo. [4]

Um contador de shares pode lembrar o progresso de um download, mas a mineração funciona de outra forma. Shares e blocos surgem da busca por hashes suficientemente baixos, com resultados aleatórios. Mais trabalho demonstrado oferece uma base estatística melhor para estimar a capacidade, não a certeza do próximo acerto. Uma longa sequência de shares aceitas não garante um bloco na tentativa seguinte. O contador informa Petr sobre trabalho e aceitação, não sobre uma última parte do bloco ainda por terminar. [3]