DigiByte: por que seu share não foi um bloco

O MultiShield do DigiByte recalcula o alvo de mineração SHA-256 toda vez que um bloco chega em qualquer um dos seus cinco algoritmos — em média a cada 15 segundos. A dificuldade de rede que você vê em um explorador, um dashboard ou um relatório de mineração é um retrato já desatualizado. Um share que supera esse valor só é um bloco válido se superar o alvo em vigor no segundo exato em que chega ao pool. Esse é o motivo mais comum pelo qual um minerador solo no DigiByte vê um share recorde e não ganha nada.

Pontos principais

• No DigiByte o alvo SHA-256 é recalculado toda vez que um bloco chega em qualquer um dos cinco algoritmos, não só quando um bloco SHA-256 é encontrado.
• Em uma janela de 90 minutos, a dificuldade dos blocos SHA-256 foi de 418 milhões a 1,12 bilhão — um fator de 2,7.
• Em um único trecho de dois minutos o alvo ativo subiu 75%, de 748 milhões para 1,31 bilhão.
• O valor de um share depende do alvo no segundo em que ele chega. O mesmo share pode ficar curto em um momento e vencer um ou dois minutos depois.
• Nada disso significa que um bloco foi perdido. Um share abaixo do alvo ativo nunca é enviado como bloco, então não há nada para ficar órfão, ser rejeitado ou escondido.

Por que meu share superou a dificuldade da rede e não encontrou um bloco?

Um minerador solo de DigiByte nos enviou um relato cuidadoso e bem fundamentado. O minerador dele tinha produzido um share de cerca de 997 milhões de dificuldade. Um relatório de mineração gerado cerca de uma hora depois mostrava uma dificuldade de rede de 531 milhões — o que tornava o share quase o dobro do alvo. Mesmo assim, nenhum bloco apareceu. Ele tinha verificado a API do pool, confirmado que o share fora recebido e aceito, e não encontrou nenhum registro de rejeição nem de share obsoleto. Por todos os números que ele podia ver, deveria ter sido um bloco.

Os números que ele podia ver eram reais. Também eram os números errados.

Rastreamos o share nos logs do pool. Ele chegou entre 06:26:31 e 06:27:31 UTC do dia 4 de outubro de 2026. Naquele minuto a rede não exigia 531 milhões. Exigia de 1,13 a 1,21 bilhão. O share atingiu entre 82,7% e 88,1% do necessário.

O número de 531 milhões era a dificuldade uma hora depois, com o pico já passado. E a partir de 06:28:37 — um a dois minutos depois da chegada do share — o alvo caiu abaixo de 997 milhões. O mesmo share, um ou dois minutos mais tarde, teria sido um bloco.

Por que a dificuldade do DigiByte se move tanto?

O DigiByte divide a produção de blocos entre cinco algoritmos de mineração independentes — SHA-256, Scrypt, Skein, Qubit e Odocrypt — cada um minerando cerca de um em cada cinco blocos, cada um com sua própria dificuldade. A rede mira um bloco a cada 15 segundos no total, então a faixa SHA-256 tem em média um bloco a cada 75 segundos.

A dificuldade de cada faixa é controlada pelo MultiShield, a extensão multialgoritmo do DigiShield que o DigiByte introduziu em 2014. Enquanto o Bitcoin reajusta uma vez a cada 2.016 blocos, o MultiShield recalcula a dificuldade a cada bloco.

O detalhe que pega os mineradores de surpresa é que ele recalcula todas as faixas a cada bloco, não só a que o encontrou. O próprio código de consenso do DigiByte diz isso explicitamente, em um comentário acima dos parâmetros de dificuldade: a dificuldade de um algoritmo pode cair quando um algoritmo diferente resolve um bloco. Então o alvo SHA-256 não fica parado entre um bloco SHA-256 e outro. Cada bloco encontrado em Scrypt, Skein, Qubit ou Odocrypt também o move, e o resultado é um alvo que muda aproximadamente a cada 15 segundos. Nosso explicador do DigiByte cobre o algoritmo completo, lido diretamente do código de consenso.

O que o alvo realmente fez naquele minuto?

Toda vez que um novo bloco chega, o pool monta um novo job de mineração e registra o alvo que esse job precisa atingir. Estes são os valores exatos que os logs do pool registraram em torno do share:

O share chegou entre 06:26:31 e 06:27:31, enquanto o alvo estava em 1.205.245.749 e depois em 1.130.849.418. Com 996.739.624, ele atingiu entre 82,7% e 88,1% da exigência. O alvo caiu pela primeira vez abaixo do share às 06:28:37.

O que provocou essa onda fica claro quando se acrescentam os blocos SHA-256 que a rede realmente produziu na mesma janela:

Três blocos SHA-256 chegaram em 99 segundos — um a cada 33 segundos, contra um ritmo esperado de um a cada 75. A faixa SHA-256 estava bem à frente das outras quatro, e o MultiShield elevou sua dificuldade em resposta, até um pico de 1,31 bilhão. Depois, nenhum bloco SHA-256 chegou por quatro minutos e vinte e quatro segundos. À medida que blocos chegavam nos outros algoritmos, o alvo foi caindo, degrau por degrau. O share chegou logo depois da crista, enquanto o alvo ainda descia.

Os valores registrados são a exigência real da rede, não uma estimativa. Cada um dos quatro blocos SHA-256 acima foi minerado exatamente no alvo que o pool tinha registrado instantes antes, coincidindo até a unidade. Os quatro são verificáveis publicamente em qualquer explorador de DigiByte.

Por que a dificuldade do relatório não batia com o alvo?

Porque o relatório capturou um momento uma hora depois, e no DigiByte uma hora é muito tempo.

Qualquer valor de dificuldade que você olhe — em um explorador, um dashboard de pool, um relatório de mineração ou uma calculadora de rentabilidade — é o valor no instante em que foi lido. No Bitcoin esse valor dura duas semanas. No DigiByte o alvo SHA-256 é recalculado toda vez que qualquer um dos cinco algoritmos encontra um bloco, então um valor coletado às 07:34 não diz quase nada sobre o que era exigido às 06:27.

Nos noventa minutos em torno desse share, a dificuldade dos blocos SHA-256 na rede foi de cerca de 418 milhões a 1,12 bilhão — um fator de 2,7. Um share de 997 milhões era folgadamente um bloco na parte de baixo dessa faixa e ficava folgadamente curto na parte de cima.

Há outra armadilha. Os exploradores publicam a dificuldade de cada bloco como foi minerado — o valor que se aplicou ao vencedor. Não existe nenhum registro público do alvo em vigor nos segundos entre os blocos. O alvo mais alto do log acima, 1,31 bilhão, não aparece em nenhum explorador, porque nenhum bloco SHA-256 foi minerado enquanto ele estava em vigor. E, no entanto, é exatamente em um momento assim que acontecem os quase acertos.

Por que o alvo pode saltar mais do que o limite de 8% do MultiShield?

Nosso explicador do DigiByte observa que o MultiShield limita seu retarget: a dificuldade pode cair até 16% em um passo mas subir no máximo 8%. Mesmo assim, depois de cada um dos três blocos SHA-256 rápidos desta janela, o alvo subiu mais de 20% — 22,9%, 22,7% e 21,7%.

Os dois fatos não se contradizem, porque o MultiShield move uma faixa de duas maneiras distintas. Os limites de 8% e 16% restringem o retarget médio da própria faixa. A isso se soma um ajuste por algoritmo de 4% que move a faixa conforme ela esteja atrás ou à frente das outras quatro.

Nesta janela, o segundo mecanismo produziu um claro dente de serra. Cada bloco em outro algoritmo baixou o alvo SHA-256 em cerca de 4–5%. Cada bloco SHA-256, chegando quando a faixa já estava à frente, empurrou-o bruscamente para cima de novo. Releia o log de alvos com isso em mente e o padrão é inconfundível: três grandes degraus para cima, cada um após um bloco SHA-256, e depois uma longa escada para baixo.

Em que isso difere do Real-Time Targeting do eCash?

O sintoma é idêntico — um share supera a dificuldade publicada e não ganha nada — mas o mecanismo não.

No eCash o destino de um share depende de quanto tempo faz que o último bloco chegou; documentamos isso em detalhe em eCash RTT: por que seu share solo não foi um bloco. No DigiByte depende de onde o alvo SHA-256 estava após o bloco mais recente em qualquer algoritmo. Ambos produzem quase acertos que, do lado do minerador, parecem exatamente um bloco perdido.

Isso acontece no Bitcoin ou nas outras redes SHA-256?

Não desta forma. Na maioria das redes SHA-256 o alvo fica fixo durante todo um intervalo de bloco e só muda quando essa rede encontra o próximo bloco.

No Bitcoin e no Bitcoin Cash, a dificuldade que você consulta é a que precisava superar. No DigiByte o alvo que decidiu seu share existiu por poucos segundos e nunca foi publicado em lugar nenhum.

O bloco foi perdido, ficou órfão ou foi escondido?

Não — porque nunca houve um bloco.

O pool registra um evento de solução de bloco toda vez que um share atinge o alvo de rede do seu job. Para esse share não houve nenhum. O pool o avaliou contra o alvo ativo, viu que ficou curto e o aceitou como um share comum. Nenhum bloco foi montado, nenhuma chamada submitblock foi feita e nada foi enviado à rede. Não havia nada para ficar órfão, ser rejeitado ou perdido.

Em um pool não custodial isso pode ser verificado de fora. O endereço de pagamento do minerador é escrito na transação coinbase do template do bloco antes de o hashing começar, então qualquer bloco real aparece on-chain no nome do minerador, de forma permanente. Um share que nunca virou bloco não deixa esse tipo de rastro — e um bloco real não poderia ser escondido se tivesse existido.

O que um minerador solo de DigiByte deve realmente fazer?

Quase nada — mas leia seus números corretamente.

• Trate todo valor de dificuldade como um retrato. Um best share acima da dificuldade no seu dashboard ou no relatório não é prova de um bloco perdido. É prova de que o alvo estava mais alto quando seu share chegou.
• O best share exibido pelo minerador é calculado localmente. Os mineradores registram a dificuldade de um hash no instante em que o encontram, antes de o pool responder, e muitas vezes guardam um valor histórico que nunca é zerado. Ele diz que seu hardware teve um bom momento, não se aquele momento foi vencedor.
• Deixe o vardiff controlar a dificuldade dos shares. O DigiByte reajusta a cada bloco, então uma dificuldade fixa de shares que serve para uma hora pode estar errada na hora seguinte. Nosso guia de configuração do DigiByte explica a configuração.
• Mantenha a latência baixa. Em uma rede de 15 segundos, um servidor próximo encurta o intervalo entre o surgimento de um novo job e o momento em que seu minerador trabalha nele.
• Confira a coinbase, não o contador. Para saber se encontrou um bloco, procure seu endereço em uma transação coinbase on-chain.

Nada disso muda suas chances no longo prazo. As oscilações se compensam com o tempo, e é por isso que uma probabilidade baseada na dificuldade média — como na nossa calculadora de probabilidades solo — continua sendo a base certa para as expectativas. As oscilações só decidem quais quase acertos específicos viram blocos.

Fontes

• Parâmetros de consenso do DigiByte Core — a nota de que a dificuldade é atualizada para cada algoritmo a cada bloco, e as constantes do MultiShield nMaxAdjustUpV4 = 8, nMaxAdjustDownV4 = 16 e nLocalTargetAdjustment = 4
• DigiByte Core — pow.cpp, o ajuste de dificuldade do MultiShield (GetNextWorkRequiredV4)
• DigiByte (DGB) explicado para mineradores — nosso perfil completo do MultiShield, lido diretamente do código de consenso
• Measuring expected block timing for Difficulty Adjustment — Josiah Spackman sobre o MultiShield e o retarget a cada bloco

Os valores de alvo deste artigo vêm dos logs do pool de 4 de outubro de 2026, registrados toda vez que um novo job de mineração era montado. Os quatro blocos SHA-256 minerados na janela — 24.323.739, 24.323.740, 24.323.742 e 24.323.752 — correspondem exatamente ao alvo que o pool registrou instantes antes de cada um, o que confirma que os valores registrados são a exigência real da rede. Todas as dificuldades de bloco citadas são verificáveis publicamente em qualquer explorador de DigiByte.