Timewarp Attack é a manipulação coordenada dos horários nos cabeçalhos dos blocos que distorce o próximo cálculo de dificuldade. Pode reduzi-la sem uma queda correspondente do hashrate e acelerar a produção de blocos.
Bitcoin recalcula a dificuldade a cada 2016 blocos e busca uma média de 10 minutos entre blocos. Subtrai o horário do primeiro bloco do período do horário do último: isso cobre apenas 2015 intervalos. O intervalo entre o último bloco de um período e o primeiro do seguinte fica fora dessas diferenças. Nessa fronteira, o tempo pode voltar sem que os cálculos liguem os períodos de forma contínua. [4] [3]
O horário de um bloco novo deve superar Median Time Past (MTP), a mediana dos horários dos 11 blocos anteriores. Não precisa superar o horário do bloco imediatamente anterior. Atacantes podem colocar quase todos os horários apenas 1 segundo acima de MTP, marcar o último bloco do período próximo da hora real e depois voltar a um horário antigo. Manipulam blocos recém-minerados, sem reescrever cabeçalhos já confirmados. [1]
O cenário clássico pressupõe a maioria do hashrate ou uma minoria com influência adicional sobre a ordem dos blocos, por exemplo via Selfish Mining. É necessário controlar a sequência temporal por bastante tempo, não apenas produzir um bloco com horário estranho. A preparação do ataque clássico leva cerca de um mês e deixa sinais publicamente visíveis na cadeia. [1]
No segundo período atacado, os horários podem sugerir uma média de 20 minutos por bloco e reduzir a dificuldade aproximadamente pela metade. O período seguinte é minerado mais rápido, mas os horários manipulados voltam a pedir uma redução. O limite de um fator quatro por ajuste não impede repetições. O limite teórico de longo prazo decorrente de MTP corresponde a cerca de 6 blocos por segundo; não é uma promessa de capacidade prática da rede. [1] [3]
Blocos mais rápidos antecipariam o subsídio futuro para um prazo menor; por si só, não aumentam o limite de 21 milhões de BTC. Os nós precisariam verificar e transmitir dados mais depressa. Processadores sobrecarregados, conexões insuficientes, ramificações concorrentes e reorganizações frequentes prejudicariam a confiabilidade das confirmações. [1]
BIP 113 usa o MTP do bloco anterior para avaliar bloqueios absolutos nLockTime definidos por horário. Os definidos pela altura do bloco continuam usando a altura. Durante o ataque, MTP pode avançar muito mais devagar que os relógios reais. Fundos sujeitos a uma condição temporal podem ficar indisponíveis por mais tempo que o esperado, e protocolos mais complexos perder a coordenação entre etapas. [5] [1]
A proposta limita o horário do primeiro bloco do período: ele não pode anteceder o bloco anterior em mais de 7200 segundos, ou duas horas. O horário do último bloco também não pode ser anterior ao do primeiro. A especificação tem status Complete. Isso significa que a proposta está concluída, não ativada: impor novas regras de consenso na mainnet exige uma ativação separada. [2]
Compare os horários dos cabeçalhos, MTP, fronteiras a cada 2016 blocos, ritmo real de mineração, dificuldade e hashrate. Diferencie o ataque clássico da variante Murch–Zawy e as regras de testnet das de mainnet. O programa pode criar preventivamente modelos de blocos mais seguros; isso não significa que toda a rede rejeite cada bloco que viole a proteção proposta. [3] [2]
Para ter uma visão mais completa, leia este verbete junto com Difficulty Adjustment, Mineração, Proof of Work, Consensus Cleanup, Timelock, Reorg. Também há referências a este verbete em Consensus Cleanup.
01O ataque exige a maioria do hashrate?+
O cenário clássico pressupõe uma maioria ou outra vantagem que dê influência suficiente sobre a ordem dos blocos. Um minerador menor sem essa vantagem não controla suficientemente seus horários.
02A proteção de Median Time Past basta?+
Não. MTP limita horários individuais, mas não fecha a lacuna nas fronteiras dos períodos. BIP 54 propõe restrições adicionais à relação entre os horários do primeiro e do último bloco.