ASICBoost teilt die Berechnung des SHA-256-Message-Schedules zwischen geeigneten Blockheader-Kandidaten. Diese besitzen einen gemeinsamen Nachrichtenteil und verschiedene Zwischenzustände; es werden keine zwei identischen endgültigen Bitcoin-Hashes gesucht.
Timo Hanke beschrieb ASICBoost 2016 und würdigte die Zusammenarbeit mit Sergio Demian Lerner. Der Entwurf verbindet Arbeitsvorbereitung außerhalb des ASIC mit der Organisation im Chip. SHA-256 und die Anforderung, dass der endgültige doppelte Header-Hash das Mining-Ziel erfüllt, bleiben gleich; wiederholte Operationen entfallen. [Timo Hanke — AsicBoost, 2016]
Ein Bitcoin-Header umfasst 80 Byte. Das erste SHA-256 verarbeitet 64 Byte und weitere 16 Byte mit Padding. Der Merkle root reicht in beide Teile: Seine letzten 4 Byte liegen im zweiten zusammen mit Zeit, bits und nonce. Deshalb zählt die genaue Position veränderter Daten. [Timo Hanke — AsicBoost, 2016]
Hankes colliding work items haben dieselbe Message und unterschiedliche midstate-Werte aus dem ersten Teil. Für einen gewählten nonce lässt sich der message schedule des zweiten Teils des ersten SHA-256 über diese Zustände hinweg wiederverwenden. Das ist keine vollständige SHA-256-Kollision; auch die ersten Header-Teile sind nicht gleich, sondern verschieden. [Timo Hanke — AsicBoost, 2016]
Lerner unterscheidet overt mit Änderungen an nVersion und covert mit Merkle root, deren letzte 4 Byte gleich sind, während der erste Teil abweicht. Covert kann Transaktionen oder deren Reihenfolge ändern, muss aber gültige Commitments und Abhängigkeiten erhalten. Ein wechselndes nVersion allein belegt weder konkrete Einsparungen noch die Identität des Betreibers. [Sergio Demian Lerner — Overt and covert AsicBoost, 2017]
BIP310 verwendet mining.configure und version-rolling.mask; die Antwort ist die Schnittmenge der Server- und Miner-Fähigkeiten. Eine Einreichung muss version_bits & ~last_mask == 0 erfüllen. mining.set_version_mask gilt sofort, nicht erst beim nächsten Job. Version rolling erlaubt weder beliebige Bitänderungen noch das Ignorieren einer neuen Maske. [BIP310 — Stratum protocol extensions]
Am Prüftag steht BIP320 auf Draft und beschreibt 16 allgemeine nVersion-Bits; BIP323 steht ebenfalls auf Draft und schlägt einen Ersatz durch 24 Bits vor. Diese Dokumente sind von tatsächlich ausgehandelter Maske und eingesetzter Software zu unterscheiden. Eine BIP-Nummer belegt weder Unterstützung aller Geräte noch beliebige Konsensänderungen. [BIP320 — General-purpose nVersion bits] [BIP323 — 24 general-purpose nVersion bits]
Hankes Modell liefert x × (n − 1) / n; x ist der Prozentanteil der geteilten Expansion, n die Zahl geeigneter Jobs. Bei x = 25% und n = 4 ergeben sich 18.75%. Das modelliert Rechenarbeit unter dieser Annahme, nicht automatisch dieselbe Watt- oder Preisersparnis oder Hashrate-Steigerung für jeden Miner. [Timo Hanke — AsicBoost, 2016]
Belegen Sie Chip- und Firmware-Unterstützung, ausgehandelte Maske, akzeptierte Arbeit und Leistungsaufnahme bei vergleichbarem Betrieb. J/TH des gesamten Geräts lassen sich nicht durch einen Funktionsnamen oder theoretischen Prozentsatz ersetzen. ASICBoost ist kein Synonym für Overclocking und garantiert weder einen Blockfund noch Gewinn. [Timo Hanke — AsicBoost, 2016] [BIP310 — Stratum protocol extensions]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit ASIC Miner, Mining, Block-Header, Proof of Work. Auf diesen Eintrag verweisen außerdem Mining Firmware.