236 / 691BOOST

ASICBoost

Reutilizar parte do cálculo entre candidatos de cabeçalho

ASICBoost reduz trabalho repetido no cálculo de mineração. Não contorna o hash alvo nem as regras de validade; o benefício depende do chip, da preparação dos trabalhos e das alterações de cabeçalho permitidas.

ASICBoost compartilha o cálculo do message schedule de SHA-256 entre candidatos adequados de cabeçalho. Eles têm uma parte comum da mensagem e estados intermediários diferentes; não se trata de encontrar dois hashes finais de Bitcoin idênticos.

Timo Hanke descreveu ASICBoost em 2016 e reconheceu a colaboração com Sergio Demian Lerner. A proposta combina preparação fora do ASIC e organização do cálculo dentro do chip. Não altera SHA-256 nem a exigência de que o hash duplo final satisfaça o alvo; economiza operações repetidas. [Timo Hanke — AsicBoost, 2016]

O cabeçalho Bitcoin tem 80 bytes. O primeiro SHA-256 o divide em 64 bytes e outros 16 acrescidos de padding. O Merkle root ocupa ambas as partes: seus últimos 4 bytes ficam na segunda, com tempo, bits e nonce. Por isso importa a posição exata dos dados alterados. [Timo Hanke — AsicBoost, 2016]

Os colliding work items de Hanke têm o mesmo Message e diferentes midstate da primeira parte. Para um nonce escolhido, reutiliza-se o message schedule da segunda parte do primeiro SHA-256 entre esses estados. Não é uma colisão do SHA-256 completo nem igualdade das primeiras partes do cabeçalho: elas diferem. [Timo Hanke — AsicBoost, 2016]

Lerner distingue overt, que modifica nVersion, e covert, que busca Merkle root com os mesmos últimos 4 bytes e primeira parte diferente. Covert pode alterar transações ou sua ordem, mantendo compromissos e dependências válidos. Um nVersion variável sozinho não comprova economia específica nem identidade do operador. [Sergio Demian Lerner — Overt and covert AsicBoost, 2017]

BIP310 usa mining.configure e version-rolling.mask; a resposta é a interseção das capacidades do servidor e do minerador. A submissão deve cumprir version_bits & ~last_mask == 0. mining.set_version_mask vale imediatamente, não apenas no próximo trabalho. Version rolling não permite alterar bits arbitrários nem ignorar uma nova máscara. [BIP310 — Stratum protocol extensions]

Na data de revisão, BIP320 está em Draft e descreve 16 bits gerais de nVersion; BIP323 também está em Draft e propõe substituí-los por 24 bits. Distinga esses documentos da máscara e do software realmente usados na conexão. Um número BIP não comprova suporte universal nem mudanças arbitrárias de consenso. [BIP320 — General-purpose nVersion bits] [BIP323 — 24 general-purpose nVersion bits]

O modelo de Hanke resulta em x × (n − 1) / n, sendo x a porcentagem da expansão compartilhada e n o número de trabalhos adequados. Para x = 25% e n = 4, resulta 18.75%. É um modelo de trabalho computacional sob essa hipótese, não automaticamente a mesma redução de watts, preço ou aumento de hashrate de todo minerador. [Timo Hanke — AsicBoost, 2016]

Documente suporte do chip e firmware, máscara negociada, trabalho aceito e consumo em operação comparável. J/TH do equipamento completo não podem ser substituídos pelo nome de uma função nem por uma porcentagem teórica. ASICBoost não é sinônimo de overclocking e não garante encontrar um bloco ou obter lucro. [Timo Hanke — AsicBoost, 2016] [BIP310 — Stratum protocol extensions]

Para ter uma visão mais completa, leia este verbete junto com ASIC Miner, Mineração, Cabeçalho de bloco, Proof of Work. Também há referências a este verbete em Mining Firmware.

DOC · 001Timo Hanke — AsicBoost, 2016Fonte primária ↗DOC · 002Sergio Demian Lerner — Overt and covert AsicBoost, 2017Fonte primária ↗DOC · 003BIP310 — Stratum protocol extensionsEspecificação ↗DOC · 004BIP320 — General-purpose nVersion bitsEspecificação ↗DOC · 005BIP323 — 24 general-purpose nVersion bitsEspecificação ↗
Fontes em primeiro lugar · Não é recomendação de investimento