Share Difficulty

Kopanie generuje hashe, czyli wyniki obliczeń, które można odczytać jako liczby. Aby pula mogła przyjąć wynik, nie może on przekraczać ustalonego celu. Niższy cel jest bardziej wymagający, bo mniej wyników mieści się pod tą granicą. Share Difficulty rośnie więc wtedy, gdy liczbowy cel maleje. Dla zainteresowanych protokołem: Stratum V2, zasady komunikacji z pulą, przekazuje tę granicę w polu target komunikatu SetTarget. Nie trzeba znać formatu wiadomości, by zrozumieć zasadę: niższy limit liczbowy oznacza trudniejszy warunek dla górnika. [1]

Wyobraź sobie, że pula podnosi trudność Petry z 1024 do 2048. Przy tej samej mocy obliczeniowej i metodzie przeliczania oczekujemy w takim samym okresie około połowy pasujących wyników. Maszyna próbuje równie szybko jak wcześniej; mniej prób przechodzi tylko przez bardziej wymagający filtr. Odstępy między wynikami pozostają losowe. Petra nie powinna więc oczekiwać, że każdy kolejny share pojawi się dokładnie po dwukrotnie dłuższym czasie. [2]

Liczenie wyłącznie wiadomości oznaczałoby porównywanie różnych rzeczy. Braiins wyjaśnia więc rozliczanie za pomocą jednostek pracy przeliczanych według trudności. Dwa przyjęte wyniki o trudności 1024 mają łącznie taką samą wagę jak jeden o trudności 2048. Mniej wiadomości nie dowodzi zatem mniejszego wkładu. Petra nie powinna też utożsamiać tej wagi rozliczeniowej z dokładną liczbą rzeczywiście wykonanych obliczeń: jest to statystyczny dowód pracy. Wynagrodzenie pieniężne zależy dodatkowo od zasad puli. [3]

Zmiana Share Difficulty sama w sobie nie przyspiesza układu ASIC, specjalizowanego chipu w koparce. Nie zmienia również celu sieciowego dla bloku Bitcoin. Przy tej samej liczbie niezależnych prób i tej samej trudności sieci szansa znalezienia bloku pozostaje bez zmian. Pula zmienia tylko to, jakie wyniki chce otrzymywać na bieżąco. Obniżenie trudności shares nie ułatwia zatem tworzenia bloków Bitcoin. [3]

Przy identycznych ustawieniach słabsze i mocniejsze urządzenia wysyłałyby bardzo różne liczby wyników. VarDiff, automatyczne dostosowanie trudności, wyrównuje tę różnicę i ogranicza zbędny ruch. Braiins pozwala też ustawić minimum. To dolna granica, a nie stała przydzielona wartość: pula może wybrać wyższą trudność zależnie od mocy obliczeniowej. Porównując ustawienia z bieżącym odczytem, Petra musi najpierw ustalić, czy widzi minimum, czy faktycznie przydzieloną trudność. [2]

Oprogramowanie musi wiedzieć, do jakiej pracy odnosi się zmiana. Według obecnej specyfikacji Stratum V2 komunikat SetTarget obejmuje zadania odebrane później oraz wcześniej odebrane zadania przyszłe z pustym ntime_start. To pole określa początkowy znacznik czasu w nagłówku bloku, który zawiera jego najważniejsze dane. Puste pole oznacza, że zadanie wciąż czeka na aktywację. Zadanie już odebrane z uzupełnionym ntime_start zachowuje swój cel. Przy badaniu odrzucenia nie wystarczy więc porównać wyniku z najnowszą granicą: trzeba przypisać go do właściwego zadania. Zwykle zajmuje się tym oprogramowanie koparki. [1]

Petra może też natrafić na wskaźnik best share. Na przykład Braiins Solo oznacza nim share o najwyższej trudności znaleziony podczas sesji kopania. Przydzielona trudność określa warunek wystarczający do zgłoszenia wyniku, a best share opisuje, jak rzadki wynik faktycznie udało się uzyskać. Rekord nie jest zgromadzonym postępem na drodze do bloku. Nawet wyjątkowy wynik nie zwiększa szans następnej niezależnej próby. [4]

Zbyt wysokie ręcznie ustawione minimum może sprawić, że zgłoszenia będą tak rzadkie, iż oszacowana moc obliczeniowa zacznie mocno się wahać. Monitoring może wtedy zgłosić alarm, choć ASIC nadal działa. Krótka przerwa bez share sama w sobie nie dowodzi awarii. Petra porównuje więc przydzieloną trudność, czas obserwacji, przyjętą pracę i stan połączenia. Dopiero razem te informacje pomagają odróżnić zwykłą losowość od rzeczywistego problemu. [2]