Jeff Garzik

Na GitHubie Jeff Garzik używa nazwy jgarzik. Jego pracę można prześledzić w poszczególnych repozytoriach, publicznych zbiorach kodu i historii jego zmian. To bardziej pomocne niż przypisywanie jednej osobie niejasnej roli kogoś, kto „kieruje Bitcoinem”. W przypadku programu liczy się to, co robi i o której wersji mówimy; w przypadku propozycji — co miała zmienić. Sam profil programisty nie decyduje, którą wersję oprogramowania uruchamiają inni. [1]

README, plik przedstawiający cpuminer Garzika, opisuje go jako program do wydobycia Bitcoina za pomocą CPU, czyli procesora komputera. Wielowątkowość pozwala rozdzielać obliczenia między kilka jednocześnie wykonywanych wątków. Projekt pooler/cpuminer dla Litecoin i Bitcoin wprost wskazuje, że wywodzi się z tego programu. Przejęcie kodu i rozwijanie go osobno nazywa się forkiem projektu. Samo w sobie nie dzieli to sieci Bitcoina, a funkcje dodane później w pochodnej wersji nie musiały istnieć w oryginale Garzika. [2] [3]

Innym przykładem jest Picocoin. Zawiera libccoin, bibliotekę w języku C, której funkcji programiści mogą używać do budowy aplikacji bitcoinowych. README oznacza jednak powiązany portfel HD i węzeł brd jako WIP, czyli prace w toku. Portfel HD wyprowadza rodzinę kluczy ze wspólnej podstawy, a węzeł ma komunikować się z siecią Bitcoina. Repozytorium zarchiwizowano 15 lutego 2024 roku. To przydatne źródło historyczne, lecz sam dostęp do kodu nie dowodzi, że produkt jest ukończony, utrzymywany i bezpieczny dla własnych oszczędności. [4]

Wyobraźmy sobie węzeł, który chce sprawdzić, jakie niepotwierdzone transakcje zna połączony z nim węzeł. BIP 35 Garzika opisuje taki mechanizm: komunikat mempool prosi o listę, odpowiedź inv zawiera identyfikatory transakcji, ich hashe, a getdata pozwala następnie poprosić o same dane. Mempool jest lokalną „poczekalnią” przed potwierdzeniem, nie jednym spisem dla całego świata. Również polecenie getrawmempool w dokumentacji Bitcoin Core zwraca zawartość konkretnego węzła. Znaleziona tam transakcja nie jest przez to potwierdzona w bloku. [5] [8]

Rozmiar bloków wpływa na miejsce dla transakcji oraz zasoby potrzebne do ich przesyłania i weryfikacji. W BIP 100 Garzik, Tom Harding i Dagur Valberg Johannsson zaproponowali zmianę limitu na podstawie głosów zapisywanych przez górników w blokach. Przeliczenie następowałoby co 2016 bloków, przy wymaganym poparciu 75% wyrażonym w blokach i ograniczonej skali kolejnych zmian. Nie chodziło więc o liczenie osób. Rejestr oznacza propozycję jako Closed, czyli zamkniętą; opis nie jest dowodem przyjęcia mechanizmu przez całą sieć Bitcoina. [6]

Weźmy zwykły węzeł, który nadal sprawdza pierwotny limit 1 MB. Gdy otrzyma większy blok, odrzuci go nawet wtedy, gdy górnik, który go wydobył, popiera wyższą granicę. BIP 100 ostrzega właśnie przed takim podziałem. Głos w bloku jest informacją dla nowego oprogramowania, a nie poleceniem przepisującym stary program. Zmiana dopuszczająca bloki odrzucane przez wcześniejsze reguły to Hard Fork. Takie znaczenie słowa fork różni się od zwykłego utworzenia pochodnego projektu na GitHubie. [6]

BIP 102 Garzika proponował inną drogę: jednorazowo podnieść limit do 2 MB. Aktywacja wymagałaby jednocześnie spełnienia warunku czasowego oraz sygnalizacji poparcia w 95% z ostatnich 1000 bloków. Spełnienie tych warunków nie zmieniłoby samo starszych programów weryfikujących, które dalej odrzucałyby większe bloki. Także ta propozycja ma status Closed. Dokumentuje planowaną zmianę, a nie reguły rozmiaru bloków obowiązujące w Bitcoinie dzisiaj. [7]

W każdym BIP należy czytać zarówno treść, jak i status. BIP 35 widnieje jako Deployed, czyli wdrożony, w warstwie Peer Services dotyczącej usług i komunikacji między węzłami. BIP 100 i BIP 102 są Closed w warstwie Consensus (hard fork), ponieważ określają, które bloki węzły uznają za prawidłowe. Ten sam autor może działać w obu obszarach z różnymi rezultatami. Udane wprowadzenie komunikatu sieciowego nie oznacza wdrożenia wszystkich proponowanych przez niego zmian reguł. [5] [6] [7]