387 / 736GAVIN

Gavin Andresen

Wczesny programista, twórca faucet i autor BIP

Gavin Andresen pomagał ludziom wypróbować Bitcoin, a programistom dalej go rozwijać. Rozdawał monety początkującym, utrzymywał oprogramowanie i proponował zmiany zasad. Jego historia pokazuje, dlaczego nawet wpływowy programista nie może decydować za całą sieć.

Gavin Andresen to wczesny programista Bitcoina i były główny opiekun jego oprogramowania. Stworzył Bitcoin Faucet, usługę rozdającą monety do wypróbowania, oraz napisał propozycje BIP 16 i BIP 101. Ich różne losy pomagają odróżnić pomysł od przyjętej zasady.

Oprogramowanie nie utrzymuje się samo, kiedy twórca projektu się wycofuje. Ktoś musi koordynować poprawki, testy i nowe wydania. Gavin Andresen przejął tę odpowiedzialność po Satoshim we wczesnych latach Bitcoina. Tak opisuje go profil MIT przygotowany na spotkanie 17 listopada 2015 roku, który jako głównego opiekuna wymienia już Wladimira van der Laana. To rola w rozwoju programu, nie własność sieci. Dawny biogram nie potwierdza też dzisiejszego dostępu do repozytorium, czyli wspólnego miejsca przechowywania kodu źródłowego. [1]

Początkujący może rozumieć cyfrowy pieniądz, ale bez monet trudno mu sprawdzić ich odbieranie i wysyłanie. Andresen odpowiedział na ten problem usługą Bitcoin Faucet. Ogłosił ją 11 czerwca 2010 roku, z początkowym zasobem 1 100 BTC i wypłatą pięciu monet na próbę. Użytkownik nie musiał czekać, aż coś wydobędzie, ani szukać sprzedawcy. Faucet rozdawał istniejące środki; nie tworzył nowych bitcoinów ani nagrody za blok. Miał ułatwić pierwsze doświadczenie, nie zmieniać zasad emisji pieniądza. [2]

W odpowiedzi z 11 czerwca 2010 roku Andresen sprecyzował limit: pięć monet na adres IP, nie każdego dnia. Adres IP oznacza połączenie w sieci komputerowej; nie jest adresem portfela bitcoinowego ani wiarygodnym spisem osób. Ochrona usługi nie była więc weryfikacją tożsamości. CAPTCHA, zadanie pomagające odróżnić człowieka od automatycznego programu, pojawiała się wtedy jako możliwy kolejny środek. Ten początkowy stan należy oddzielać od późniejszych zmian, zamiast odtwarzać historię na podstawie dzisiejszych usług. [2]

Inny wkład dotyczył odrębnego problemu praktycznego. Odbiorca może wymagać kilku podpisów przed wydaniem pieniędzy. Czy nadawca musi za każdym razem obsługiwać całą taką regułę? BIP 16 z 2012 roku opisuje Pay to Script Hash: płatność odwołuje się do hasha, krótkiego cyfrowego odcisku skryptu zawierającego warunki. BIP to numerowana propozycja ulepszenia Bitcoina. Sam skrypt, tutaj nazwany redeemScript, przedstawia dopiero osoba wydająca środki. Warunki nie znikają; zmienia się moment ich dostarczenia i odpowiedzialna za to strona. [3]

Wyobraź sobie kasę otwieraną za zgodą kilku osób. Pokazanie jej regulaminu nie wydaje pieniędzy. Podobnie BIP 16 z 2012 roku wymaga sprawdzenia hasha dostarczonego redeemScript, a następnie wykonania jego warunków. Znajomość skryptu nie zastępuje wymaganych podpisów. Istnieje też techniczny limit 520 bajtów dla tego wstawianego skryptu; bajt jest jednostką wielkości danych. Początkujący powinien rozróżnić dwie kontrole: czy przedstawiono właściwą regułę i czy dostarczono to, czego ona wymaga. [3]

W 2015 roku Andresen przedstawił BIP 101, proponując stopniowy wzrost maksymalnego rozmiaru bloku. Dokument określa zmianę jako Hard Fork: starsze zasady odrzucałyby niektóre bloki dopuszczone przez nowe. Rejestr oznacza tę propozycję jako Closed, czyli zamkniętą. BIP 16 ma natomiast status Deployed, czyli wdrożony. Numer BIP ani znane nazwisko autora nie dowodzą zatem aktywacji. Czytając propozycję, trzeba również sprawdzić, czy jej zasady faktycznie zaczęły obowiązywać. [4] [3]

Dlaczego zwiększanie bloków budziło spór? Większy blok mieści więcej transakcji, ale jego dane trzeba rozesłać, odebrać i sprawdzić. BIP 101 z 2015 roku omawia więc koszty transmisji oraz ryzyko, że większe wymagania będą sprzyjać dużym operatorom. Osoba z wolnym łączem może być w innej sytuacji niż duża firma wydobywcza. Oczekiwania autora dotyczące postępu technicznego są argumentem za propozycją, nie zmierzonym wynikiem dla każdych przyszłych warunków. Chodzi o pogodzenie pojemności z możliwością samodzielnego weryfikowania sieci. [4]

Bitcoin.org wyjaśnia, że programiści nie mogą narzucić użytkownikom zmiany zasad: ludzie wybierają uruchamiane oprogramowanie. Aby współpracować, uczestnicy muszą zachować zgodność reguł. Andresen mógł pisać propozycje i kod oraz przekonywać innych, lecz nie mógł jednostronnie zmienić Bitcoina dla wszystkich. Jego pracę warto oceniać przez konkretne dokonania: co umożliwiała usługa, co robił kod i co przyjęła sieć. Wcześniejsze zasługi nie dowodzą automatycznie prawdziwości każdego późniejszego twierdzenia. [5]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Laszlo Hanyecz, Amir Taaki, Satoshi Nakamoto. Do tego hasła prowadzą również odsyłacze z Satoshi Nakamoto, Laszlo Hanyecz, Amir Taaki.

DOC · 001MIT Media Lab — MLTalks developer biographies (2015)Dokumentacja DOC · 002Gavin Andresen — Original Bitcoin Faucet announcement and replies (2010)Dokumentacja DOC · 003Gavin Andresen — BIP 16: Pay to Script HashDokumentacja DOC · 004Gavin Andresen — BIP 101: Increase maximum block sizeDokumentacja DOC · 005Bitcoin.org — About bitcoin.orgDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna