ASICBoost współdzieli obliczanie harmonogramu wiadomości SHA-256 między odpowiednio przygotowanymi kandydatami nagłówka bloku. Mają wspólną część wiadomości i różne stany pośrednie; nie chodzi o znalezienie dwóch jednakowych końcowych hashy Bitcoin.
Timo Hanke opisał ASICBoost w 2016 roku i wskazał współpracę z Sergio Demian Lerner. Projekt łączy przygotowanie pracy poza ASIC z organizacją obliczeń wewnątrz układu. Nie zmienia SHA-256 ani wymogu spełnienia celu przez końcowy podwójny hash nagłówka; oszczędza powtarzane operacje. [Timo Hanke — AsicBoost, 2016]
Nagłówek Bitcoin ma 80 bajtów. Pierwszy SHA-256 dzieli go na 64 bajty i pozostałe 16 bajtów uzupełnione paddingiem. Merkle root obejmuje obie części: ostatnie 4 bajty znajdują się w drugiej wraz z czasem, bits i nonce. Znaczenie ma dokładna pozycja zmienianych danych. [Timo Hanke — AsicBoost, 2016]
Hanke nazywa odpowiednie zadania colliding work items: mają ten sam Message i różne midstate z pierwszej części. Dla wybranego nonce można ponownie użyć message schedule drugiej części pierwszego SHA-256 między tymi stanami. Nie jest to kolizja całego SHA-256 ani identyczność pierwszych części nagłówka: one są różne. [Timo Hanke — AsicBoost, 2016]
Lerner rozróżnia overt zmieniające nVersion oraz covert szukające Merkle root o tych samych ostatnich 4 bajtach i innej pierwszej części. Covert może zmieniać transakcje lub ich kolejność, zachowując poprawne zobowiązania i zależności. Zmienny nVersion sam nie dowodzi określonej oszczędności ani tożsamości operatora. [Sergio Demian Lerner — Overt and covert AsicBoost, 2017]
BIP310 wykorzystuje mining.configure i version-rolling.mask; odpowiedź to część wspólna możliwości serwera i górnika. Zgłoszenie musi spełniać version_bits & ~last_mask == 0. mining.set_version_mask obowiązuje natychmiast, a nie od kolejnego zadania. Version rolling nie pozwala zmieniać dowolnych bitów ani ignorować nowej maski. [BIP310 — Stratum protocol extensions]
W dniu przeglądu BIP320 ma status Draft i opisuje 16 ogólnych bitów nVersion; BIP323 również ma Draft i proponuje zastąpienie ich 24 bitami. Odróżniaj dokumenty od faktycznej maski i oprogramowania danego połączenia. Numer BIP nie dowodzi obsługi przez wszystkie urządzenia ani dowolnej zmiany konsensusu. [BIP320 — General-purpose nVersion bits] [BIP323 — 24 general-purpose nVersion bits]
Model Hanke daje x × (n − 1) / n, gdzie x to procentowy udział współdzielonego rozwinięcia, a n liczba odpowiednich zadań. Dla x = 25% i n = 4 wynik to 18.75%. To model pracy obliczeniowej przy tym założeniu, nie automatycznie taka sama oszczędność watów, ceny czy wzrost hashrate każdego urządzenia. [Timo Hanke — AsicBoost, 2016]
Udokumentuj obsługę układu i firmware, wynegocjowaną maskę, przyjętą pracę oraz pobór mocy w porównywalnych warunkach. J/TH całego urządzenia nie zastąpi nazwa funkcji ani teoretyczny procent. ASICBoost nie oznacza overclockingu i nie gwarantuje znalezienia bloku ani zysku. [Timo Hanke — AsicBoost, 2016] [BIP310 — Stratum protocol extensions]
Pełniejszy obraz uzyskasz, czytając to hasło razem z ASIC Miner, Górnictwo Bitcoin, Nagłówek bloku, Proof of Work. Do tego hasła prowadzą również odsyłacze z Mining Firmware.