Hashcash

Anna quer enviar um e-mail a Pavel. Mandar outra cópia quase não lhe custa nada, mas quem dispara milhões de anúncios tem a mesma vantagem. O Hashcash acrescenta um pequeno obstáculo: o computador do remetente primeiro produz um selo computacional. O custo é tempo e energia, não um pagamento aos correios. Adam Back anunciou sua implementação em 28 de março de 1997 e publicou uma descrição técnica em 2002. Cynthia Dwork e Moni Naor já haviam estudado uma ideia semelhante em 1992. O Hashcash faz parte dessa busca por formas de limitar abusos da rede. [1] [12]

Um hash é uma impressão digital de tamanho fixo calculada a partir de dados. O programa de Anna altera um valor de tentativa no selo e recalcula a impressão até que o resultado comece com bits zero em quantidade suficiente. Um bit é um dígito binário: zero ou um. Exigir b zeros dá a cada tentativa uma probabilidade aproximada de sucesso de 2^-b, com média de 2^b tentativas. Para b = 20, são 1048576 cálculos em média, não uma quantidade exata obrigatória. Às vezes há sorte logo; às vezes demora mais. Pavel verifica o selo pronto com um cálculo de hash, mas também precisa conferir seus dados e as regras de aceitação. [10] [11]

Se Anna pudesse anexar um selo a um milhão de mensagens, o obstáculo perderia a utilidade. Por isso, o selo identifica um destinatário ou serviço e inclui uma data. O destinatário verifica a validade e registra os selos aceitos para rejeitar a reutilização, chamada replay. Nem a data nem a vinculação ao conteúdo impedem, sozinhas, o reenvio da mesma mensagem. O Hashcash não tem um registro global compartilhado de gastos: o serviço receptor faz essa verificação. Um hash correto não basta para aceitar novamente o selo. [11] [12]

O serviço receptor escolhe a dificuldade. Cada bit zero adicional aproximadamente dobra o trabalho médio. Uma exigência fraca mal atrasa o spammer; uma forte também pesa para o usuário comum. O número 20 é, portanto, um exemplo, não um padrão de segurança eterno. Além disso, a mesma quantidade de tentativas leva tempos diferentes num celular antigo e num computador rápido. O serviço precisa considerar desempenho, validade e sua própria capacidade. O Hashcash não obriga todas as pessoas a gastar um número universal de segundos. [10] [11]

O cálculo não distingue uma pessoa respeitosa de um atacante. Um spammer com muitos computadores ou uma botnet, uma rede de dispositivos comprometidos, pode distribuir o trabalho e repassar parte do custo a outras pessoas. Enquanto isso, o usuário comum consome bateria. O Hashcash procura mudar a economia do ataque, não garantir o fim do spam. O selo também não cifra a mensagem, nem comprova a identidade civil ou garante a entrega. É uma condição de aceitação que o serviço pode combinar com outras proteções. [10]

A versão 1 usa o formato 1:bits:date:resource:ext:rand:counter. Os campos indicam versão, dificuldade declarada, data, destinatário ou serviço, extensões, um valor aleatório e um contador variável. O campo bits informa quantos bits zero iniciais o remetente afirma que a impressão tem, não quantas tentativas o computador realmente fez. Esses nomes pertencem ao formato técnico e não são traduzidos. A implementação clássica calcula SHA-1 sobre a sequência inteira. A impressão real precisa cumprir a condição; escrever um número em bits não basta. É a descrição de um formato histórico, não uma recomendação de SHA-1 para novos projetos de segurança. O Bitcoin usa outro formato de dados e outra função hash. [11] [13]

Aqui buscamos uma entrada cuja impressão tenha um início predeterminado. Essa entrada é chamada de partial preimage: sua impressão atende à parte exigida, enquanto o restante pode ter qualquer valor. Uma colisão, por sua vez, ocorre quando duas entradas diferentes produzem a mesma impressão. Alguns textos históricos usam a expressão menos precisa partial collision, mas a distinção importa para entender o trabalho. Um ataque que encontra colisões de SHA-1 não resolve automaticamente a busca pelo início exigido. Isso tampouco faz de SHA-1 uma escolha geral adequada para a segurança atual. [10] [11] [13]

Em 2004, Hal Finney apresentou RPOW, Reusable Proofs of Work. O usuário podia entregar uma prova de trabalho e receber um novo token; numa transferência posterior, o antigo era invalidado e substituído por outro. Reutilização não significava copiar livremente o mesmo selo. O sistema dependia de um servidor com módulo seguro IBM 4758 e da verificação remota do programa executado. Isso reduzia a confiança necessária no operador, mas mantinha pressupostos sobre o hardware e o fabricante. RPOW era um precursor experimental, não o consenso descentralizado do Bitcoin. [7] [15]

Bitcoin Whitepaper cita explicitamente o Hashcash de Back. Satoshi aproveitou a mesma diferença: encontrar um resultado requer tentativas repetidas, enquanto os demais conseguem verificá-lo facilmente. Mineradores de Bitcoin buscam um cabeçalho de bloco válido, que resume um bloco de transações e aponta para o anterior. Usam double SHA-256, duas aplicações consecutivas de SHA-256, e comparam o resultado com um limite numérico chamado target. Não se trata de um selo de e-mail SHA-1 colocado numa carteira. O princípio é comum, não o sistema inteiro. [8] [14]

A postagem dá um custo a um pedido individual. O dinheiro também precisa determinar qual de duas transferências conflitantes é válida. O Bitcoin liga blocos, e seus nós escolhem, entre as ramificações válidas, a cadeia com maior trabalho acumulado. Os nós, computadores que verificam as regras, também conferem transações e a emissão permitida. Nem um trabalho enorme torna válida uma transação inválida. O Hashcash forneceu uma peça importante; sua combinação com outras regras permitiu um histórico monetário compartilhado sem administrador central. [8] [9]