ASICBoost partage le calcul du message schedule de SHA-256 entre des candidats d’en-tête adaptés. Ils possèdent une partie commune du message et des états intermédiaires différents ; il ne s’agit pas de trouver deux hashes Bitcoin finaux identiques.
Timo Hanke a décrit ASICBoost en 2016 en reconnaissant la collaboration de Sergio Demian Lerner. Le dispositif associe préparation hors ASIC et organisation du calcul dans la puce. Il ne modifie ni SHA-256 ni l’obligation pour le double hash final de satisfaire la cible minière ; il économise des opérations répétées. [Timo Hanke — AsicBoost, 2016]
Un en-tête Bitcoin mesure 80 octets. Le premier SHA-256 le divise en 64 octets puis 16 octets complétés par du padding. Le Merkle root occupe les deux parties : ses 4 derniers octets figurent dans la seconde avec le temps, bits et nonce. La position exacte des données modifiées est donc déterminante. [Timo Hanke — AsicBoost, 2016]
Les colliding work items de Hanke ont le même Message et des midstate différents issus de la première partie. Pour un nonce choisi, le message schedule de la seconde partie du premier SHA-256 est réutilisable entre ces états. Ce n’est ni une collision du SHA-256 complet ni une égalité des premières parties d’en-tête : celles-ci diffèrent. [Timo Hanke — AsicBoost, 2016]
Lerner distingue overt, qui modifie nVersion, et covert, qui recherche des Merkle root aux 4 derniers octets identiques mais à la première partie différente. Covert peut modifier ou réordonner les transactions tout en respectant engagements et dépendances. Un nVersion variable ne prouve à lui seul ni une économie précise ni l’identité de l’opérateur. [Sergio Demian Lerner — Overt and covert AsicBoost, 2017]
BIP310 utilise mining.configure et version-rolling.mask ; la réponse est l’intersection des capacités du serveur et du mineur. Une soumission doit respecter version_bits & ~last_mask == 0. mining.set_version_mask s’applique immédiatement, sans attendre le travail suivant. Version rolling n’autorise donc ni des changements arbitraires ni l’ignorance d’un nouveau masque. [BIP310 — Stratum protocol extensions]
À la date de révision, BIP320 est Draft et décrit 16 bits nVersion généraux ; BIP323 est également Draft et propose de les remplacer par 24 bits. Distinguez ces documents du masque et du logiciel réellement utilisés pour une connexion. Un numéro BIP ne prouve ni une compatibilité universelle ni des changements arbitraires du consensus. [BIP320 — General-purpose nVersion bits] [BIP323 — 24 general-purpose nVersion bits]
Le modèle de Hanke donne x × (n − 1) / n, où x est le pourcentage de travail d’expansion partagé et n le nombre de travaux adaptés. Avec x = 25% et n = 4, on obtient 18.75%. Ce modèle de calcul sous hypothèse ne garantit pas une économie identique de watts ou de prix, ni une hausse identique du hashrate de chaque mineur. [Timo Hanke — AsicBoost, 2016]
Pour un appareil donné, documentez puce, firmware, masque négocié, travail accepté et consommation dans des conditions comparables. Les J/TH de l’appareil complet ne se remplacent pas par un nom de fonction ou un pourcentage théorique. ASICBoost n’est pas synonyme d’overclocking et ne garantit ni découverte d’un bloc ni profit. [Timo Hanke — AsicBoost, 2016] [BIP310 — Stratum protocol extensions]
Pour une vision complète, lisez aussi ASIC Miner, Minage, En-tête de bloc, Proof of Work. Cette entrée est également citée par Mining Firmware.