Mining Target

Wyobraź sobie wyłącznie dla przykładu granicę 20: wyniki 19 i 20 pasowałyby, ale 21 już nie. W rzeczywistym kopaniu liczby są znacznie większe, lecz zależność jest taka sama: hash ≤ target. Znak oznacza mniejszy lub równy, a nie wyłącznie mniejszy. Bitcoin Core to program, którym uczestnicy sieci sprawdzają bloki i transakcje. Wskazana tu wersja v29.0 tak samo porównuje hash całego nagłówka. Nonce, wartość zmieniana przez górnika podczas poszukiwań, jest jedną z danych wejściowych. Z celem porównuje się obliczony hash. [1]

Jana widzi udany hash zaczynający się długim szeregiem zer. To przydatna ilustracja: przy zapisach o tej samej długości więcej zer na początku oznacza mniejszą liczbę. Dwa hashe z taką samą liczbą zer mogą jednak znaleźć się po przeciwnych stronach celu. Pozostałe cyfry także mają znaczenie. Zera nie zastępują więc pełnego porównania hash ≤ target. Reguła nie szuka ładnego wzoru znaków, lecz dokładnie określa warunek liczbowy. [1]

Bit zapisuje zero albo jedynkę; osiem bitów tworzy bajt. Zamiast przechowywać w nagłówku całą długą liczbę, Bitcoin używa pola nBits o długości 32 bitów. Koduje ono cel w przestrzeni liczb 256-bitowych za pomocą współczynnika, wykładnika określającego przesunięcie oraz bitu znaku. Na przykład 0x04123456 dekoduje się do 0x12345600; przedrostek 0x oznacza zapis szesnastkowy, który wykorzystuje również litery. To przykład kodowania, nie aktualny cel sieci. Na początek wystarczy rozróżnić samą liczbę i jej skrócony zapis. [3] [5]

W surowych danych ta sama liczba może wyglądać na odwróconą. W nagłówku o długości 80 bajtów nBits zajmuje cztery bajty zapisane jako little-endian: najmniej znaczący bajt znajduje się pierwszy. Dlatego liczba 0x1d00ffff pojawia się w danych jako ff ff 00 1d. Kolejność bajtów nie zmienia celu, tylko opisuje sposób przechowywania. Ten szczegół jest ważny przy pracy z surowymi danymi; zwykły czytelnik eksploratora bloków nie musi odwracać liczb na ekranie. [2]

Jana mogłaby zaproponować zapisanie większej liczby, aby ułatwić poszukiwania. Oprogramowanie sprawdza jednak coś więcej niż możliwość odczytania nBits. DeriveTarget w Bitcoin Core v29.0 odrzuca cel ujemny, zero, przepełnienie zakresu liczbowego oraz wartości ponad powLimit, najwyższym celem dozwolonym w danej sieci. Poprawne dekodowanie ustala więc tylko, jaką liczbę reprezentuje zapis; samo nie uprawnia do jej użycia. [1]

Nawet cel mieszczący się w dozwolonym zakresie może być niewłaściwy dla konkretnego bloku. Bitcoin Core porównuje nBits z GetNextWorkRequired, obliczeniem opartym na poprzednim bloku i regułach sieci. Niezgodność daje błąd bad-diffbits. Niski hash pod własnym, łatwiejszym celem nie usprawiedliwia błędnej wartości w nagłówku. Jana nie uzyska zaakceptowanego bloku przez samo obniżenie wymagań: inne węzły, czyli komputery sprawdzające reguły, odrzucą taką próbę. [4]

W modelu równomiernie rozłożonych hashów 256-bitowych każdy możliwy wynik ma jednakowe prawdopodobieństwo. Dla dozwolonego celu T akceptowane są wartości od zera do T włącznie. Stąd p = (T + 1) / 2^256 na jedną próbę; p oznacza prawdopodobieństwo sukcesu. Dodana jedynka uwzględnia zero. Zależność wyjaśnia, dlaczego niższy cel utrudnia poszukiwania. Nie mówi jednak, ile prób maszyna wykona w sekundę ani kiedy dokładnie pojawi się kolejny blok. [1]

Gdy Jana spełnia warunek, wykazuje wymaganą pracę obliczeniową, a nie poprawność całej zawartości bloku. Bitcoin Core sprawdza też zbiorczy skrót transakcji, specjalną transakcję nagrody coinbase, limity bloku oraz poprawność transakcji. Tutaj coinbase to techniczna nazwa pierwszej transakcji bloku, nie giełdy. Niski hash nie naprawia nieprawidłowej zawartości. Cel jest ważną częścią reguł, a nie pozwoleniem na ominięcie pozostałych. [4]