Mining Share

Maszyna Piotra wykonuje ogromną liczbę prób. Pula nie potrzebuje wiadomości o każdej: dostaje wybrane wyniki spełniające ustalony warunek. Może je zweryfikować i statystycznie szacować pracę z ich częstotliwości oraz trudności. Mining Share nie jest więc częścią niedokończonego bloku ani zbywalnym udziałem w bitcoinie. Nie jest też transakcją zapisywaną w blockchainie, czyli publicznej historii transakcji Bitcoin uporządkowanej w połączone bloki. Służy do wykazania puli wkładu górnika w obliczenia. [1]

Kopanie szuka hasha, wyniku obliczenia traktowanego jako liczba, nie większego od wyznaczonego celu. Pula zwykle ustala cel liczbowo wyższy niż sieć: przechodzi więcej wyników, więc jest łatwiejszy. Wynik wystarczający puli przeważnie nie wystarcza na blok. Niektóre przypadkiem spełniają również ostrzejszy cel sieci. Mogą prowadzić do nowego bloku, jeśli cały blok spełnia także pozostałe reguły. Pula nie łagodzi zasad sieci Bitcoin; ustala własny próg dla bieżącego potwierdzania pracy. [1]

Piotr nie składa tych wiadomości ręcznie; robi to oprogramowanie. Stratum V2 jest protokołem, czyli regułami komunikacji między urządzeniami a pulą. Wiadomość SubmitSharesStandard zawiera job_id określający zadanie, nonce jako wartość zmienianą podczas poszukiwań, ntime dla znacznika czasu w nagłówku bloku i version dla wersji nagłówka, zwięzłej części danych bloku. Identyfikuje też kanał komunikacji. Pula potrzebuje tego kontekstu do sprawdzenia obliczenia: samo nonce bez odpowiedniego zadania nie jest samodzielnym dowodem pracy. [2]

Wyobraź sobie, że Piotr porównuje urządzenia wykonujące zadania o różnej trudności. Trudność działa tu jak waga: wynik spełniający surowszy warunek jest zaliczany jako większy wkład pracy. Po przeliczeniu według tej samej skali dwa przyjęte zgłoszenia o trudności 1024 mają taką samą łączną wagę jak jedno o trudności 2048. Liczba wiadomości jest inna, lecz rozliczona waga pracy taka sama. Nawet ta suma nie jest dokładnym rejestrem wszystkich faktycznie wykonanych obliczeń: pojedyncze sukcesy są losowe. Trzeba zatem sprawdzić, czy licznik shares pokazuje zaakceptowane wyniki, czy ich przeliczoną wagę. [3]

Pula czasem potwierdza kilka zgłoszeń naraz. Stratum V2 używa do tego odpowiedzi SubmitShares.Success. Pole new_submits_accepted_count liczy nowo potwierdzone zgłoszenia, a new_shares_sum sumuje trudności ich zadań. Pierwsze liczy wyniki, drugie ich wagę. Oba dotyczą właśnie potwierdzanej grupy, a nie automatycznie sum z całej historii górnika. Czytając protokół, nie należy więc oczekiwać osobnego potwierdzenia każdego wysłanego wyniku. [2]

Koparka Piotra może zgłosić wysłanie wyniku, podczas gdy pula dopiero go sprawdza. Stratum V2 dla błędnego zgłoszenia używa SubmitShares.Error; sequence_number wskazuje, którego zgłoszenia dotyczy błąd. Gdy weryfikacja nie jest możliwa od razu, odpowiedź z błędem może przyjść później. Dlatego rozróżniaj wyniki wysłane i potwierdzone jako przyjęte oraz obserwuj odrzucenia. Wzrost lokalnego licznika wysyłek sam nie dowodzi, że pula wszystko zaliczyła. [2]

Potwierdzona praca podlega zasadom wynagradzania konkretnej puli. Przykładowo FPPS, Full Pay Per Share, w Braiins oblicza wynagrodzenie z dostarczonej pracy i danych sieci, w tym trudności oraz nagród za bloki; uwzględnia też składnik opłat transakcyjnych. Pula potrąca swoją opłatę, a przesyłanie środków zależy od ustawień wypłat. Potwierdzenie share samo nie wysyła BTC (bitcoinów) do portfela. Piotr obserwuje więc osobno przyjętą pracę, obliczone wynagrodzenie i rzeczywistą wypłatę. [4]

Licznik shares może przypominać pasek pobierania, ale kopanie działa inaczej. Shares i bloki powstają przez szukanie dostatecznie niskich hashy, z losowymi wynikami. Więcej potwierdzonej pracy daje lepszą podstawę statystyczną do oszacowania mocy, nie pewność kolejnego sukcesu. Długa seria zaakceptowanych shares nie gwarantuje bloku w następnej próbie. Licznik mówi Piotrowi o bieżącej pracy i jej przyjęciu, a nie o ostatnim kawałku bloku, który pozostał do ukończenia. [3]