258 / 736BWH

Block Withholding Attack

Ataque de retenção de soluções de bloco

Imagine um minerador que envia regularmente provas de trabalho a um pool. Quando encontra o resultado necessário para um bloco válido, porém, ele o esconde. No painel parece um participante ativo, enquanto o pool perde uma oportunidade de receber uma recompensa. Assim funciona o Block Withholding Attack clássico. Esse ataque à cooperação entre mineradores pode parecer simples azar. Para entendê-lo, precisamos separar as provas rotineiras de trabalho, os blocos reais e as regras de distribuição do dinheiro.

Um Block Withholding Attack ocorre quando um minerador envia provas comuns de trabalho ao pool, mas omite deliberadamente uma solução válida de bloco. O pool pode contabilizar seu trabalho sem receber as oportunidades correspondentes de obter recompensas de bloco.

Um Mining Pool reúne o trabalho de mineradores e distribui recompensas conforme regras combinadas. Não pode esperar que cada pequeno participante encontre um bloco inteiro. Como explica o Bitcoin Developer Guide, usa shares: resultados que atendem a uma condição mais fácil e demonstram continuamente o trabalho realizado. Um resultado raro também atende à condição mais exigente da rede Bitcoin. O atacante envia as shares comuns, mas descarta essa descoberta mais valiosa. A máquina realmente calcula e consome eletricidade; não está simulando mineração sem custo. [3]

Depende do modelo de pagamento. Meni Rosenfeld diferencia Pay Per Share (PPS), em que o operador paga pelas shares aceitas, de Pay Per Last N Shares (PPLNS), em que as recompensas efetivas dos blocos são distribuídas conforme as shares aceitas recentemente dentro de uma faixa definida. Em PPS, o operador suporta a falta de receita dos blocos omitidos se cumprir os pagamentos prometidos. Em PPLNS, sobra menos dinheiro para os participantes, incluindo o atacante. A mesma descoberta descartada pode, portanto, afetar pessoas diferentes. Importam as regras concretas do pool, não apenas a palavra “mineração” no painel. [1]

Descartar descobertas pode ser uma sabotagem cara. O atacante paga equipamentos e eletricidade e abre mão de receitas que poderia obter honestamente. Ittay Eyal também estuda um caso mais complexo: um pool concorrente usa parte da capacidade para mineração honesta e outra parte contra um pool diferente. Sob determinadas hipóteses, essa divisão pode aumentar sua receita total. Mas um resultado matemático não promete lucro depois de todos os custos. A perda da vítima, sozinha, não mostra se o atacante ganhou dinheiro com a operação. [2]

Os dois conceitos envolvem um bloco não publicado, mas seu destino é diferente. Eyal e Emin Gün Sirer descrevem Selfish Mining como mineração em uma ramificação privada da cadeia, com publicação estratégica de seus blocos. O atacante quer que essa ramificação prevaleça e receba recompensas. Já o Block Withholding Attack clássico dentro de um pool descarta os blocos encontrados; não precisa construir uma ramificação privada vencedora. Outras variantes apenas atrasam a entrega. Ao ler uma análise, precisamos saber qual estratégia ela realmente examina. [4]

Considere um período em que um minerador honesto encontraria, em média, 1 bloco, dada sua capacidade de cálculo e a dificuldade. O modelo de Poisson, também usado por Rosenfeld, descreve descobertas aleatórias independentes com uma taxa esperada constante. Ele indica cerca de 37% de chance de não encontrar nenhum. Com 3 blocos esperados, essa chance fica perto de 5%. Isso não é uma probabilidade de culpa: calculamos a chance de resultado zero supondo mineração honesta, não a probabilidade de fraude após observar zero. O exemplo exige condições estáveis adequadas e um período definido previamente. A média não é um prazo para o bloco aparecer. [1]

Eyal destaca a dificuldade de atribuir um ataque a um pequeno minerador específico. Uma conta sem blocos encontrados não basta. É preciso comparar shares aceitas e blocos no mesmo período, considerando a dificuldade das shares e, portanto, o trabalho que representam. Hashrate é a velocidade de cálculo; sua estimativa a partir dessas provas também oscila. Interrupções, registros ausentes e mudanças nas condições precisam ser examinados. O pool pode ter motivo para investigar um problema sem ter provas suficientes para acusar uma pessoa. [2]

Eyal discute bônus por encontrar blocos, construção de reputação e tarefas de teste com solução conhecida. Cada proposta muda alguma coisa. O bônus concentra mais recompensa no descobridor e pode aumentar a oscilação da renda dos pequenos mineradores. Regras de reputação dificultam a troca de pool; tarefas de teste exigem manutenção e avaliação confiável. Não se trata de uma proteção universal que basta ativar. O operador precisa avaliar eficácia e efeitos colaterais e explicar com honestidade o que suas medidas conseguem detectar. [2]

O Bitcoin Developer Guide distingue encontrar um bloco de sua validação pela rede. Ocultar uma descoberta não altera regras de validade das transações nem permite, por si só, gastar moedas de outras pessoas ou reescrever o histórico confirmado. O principal dano está na economia e na confiança da cooperação entre mineradores. Três perguntas ajudam: o que foi ocultado, quem perdeu dinheiro segundo as regras combinadas e quais provas existem? Descrever esse mecanismo não acusa nenhum pool atual. [3]

Para ter uma visão mais completa, leia este verbete junto com Mining Pool, Pay Per Last N Shares, Hashrate, Selfish Mining.

DOC · 001Rosenfeld — Analysis of Bitcoin Pooled Mining Reward SystemsFonte primária DOC · 002Eyal — The Miner’s DilemmaFonte primária DOC · 003Bitcoin Developer Guide — MiningDocumentação DOC · 004Eyal and Sirer — Majority is not EnoughFonte primária
Revisto em: Fontes em primeiro lugar · Não é recomendação de investimento