387 / 736GAVIN

Gavin Andresen

Raný vývojář, autor faucetu a návrhů BIP

Gavin Andresen pomáhal lidem Bitcoin vyzkoušet a vývojářům jej dál rozvíjet. Rozdával mince začátečníkům, spravoval software a navrhoval změny pravidel. Jeho příběh dobře ukazuje, proč ani významný vývojář nemůže rozhodovat za celou síť.

Gavin Andresen je raný vývojář Bitcoinu a někdejší hlavní správce jeho softwarového projektu. Založil Bitcoin Faucet, službu rozdávající mince k vyzkoušení, a napsal technické návrhy BIP 16 a BIP 101. Jejich odlišný osud pomáhá pochopit, jak se návrh liší od přijatého pravidla.

Když tvůrce projektu ustoupí do pozadí, software se nezačne udržovat sám. Někdo musí koordinovat opravy, testování i vydávání nových verzí. Gavin Andresen tuto odpovědnost v raném Bitcoinu převzal po Satoshim. Tak ho popisuje také profil MIT k setkání ze 17. listopadu 2015, který už jako hlavního správce uvádí Wladimira van der Laana. Jde o roli ve vývoji programu, nikoli vlastnictví sítě. Historický životopis navíc není dokladem dnešního přístupu k repozitáři, tedy společnému úložišti zdrojového kódu. [1]

Začátečník může rozumět myšlence digitálních peněz, ale bez mincí těžko vyzkouší jejich přijetí a odeslání. Andresen tuto překážku řešil službou Bitcoin Faucet. Oznámil ji 11. června 2010, vložil do ní počátečních 1 100 BTC a nabízel pět mincí na vyzkoušení. Návštěvník tak nemusel čekat, až něco vytěží, ani shánět prodejce. Faucet rozdával existující prostředky; nevytvářel nové bitcoiny ani blokovou odměnu. Smyslem bylo usnadnit první zkušenost, ne změnit pravidla vydávání peněz. [2]

V odpovědi z 11. června 2010 Andresen upřesnil limit: pět mincí na IP adresu, nikoli každý den. IP adresa označuje připojení v počítačové síti; není to adresa bitcoinové peněženky ani spolehlivý seznam jednotlivých lidí. Ochrana služby proto nebyla totéž jako ověření totožnosti. CAPTCHA, tedy úkol pomáhající odlišit člověka od automatického programu, tehdy patřila mezi zvažovaná opatření. Je dobré rozlišit tento počáteční stav od pozdějších úprav a nepřepisovat historii podle toho, jak podobné služby vypadají dnes. [2]

Další Andresenův příspěvek řešil jiný praktický problém. Příjemce může chtít, aby se s penězi smělo nakládat až po získání několika podpisů. Má odesílatel pokaždé pracovat s celým takovým pravidlem? BIP 16 z roku 2012 popisuje Pay to Script Hash: platba odkazuje na hash, krátký digitální otisk skriptu s podmínkami. BIP je očíslovaný návrh popisující zlepšení Bitcoinu. Samotný skript, zde nazvaný redeemScript, dodá až ten, kdo prostředky utrácí. Nejde o odstranění podmínek, ale o přesun okamžiku a odpovědnosti za jejich předložení. [3]

Představte si pokladnu, k jejímuž otevření je třeba souhlas více lidí. Ukázat její pravidla vám samo o sobě peníze nevydá. Podobně BIP 16 z roku 2012 vyžaduje ověřit hash předloženého redeemScript a potom vykonat jeho podmínky. Znalost skriptu nenahrazuje potřebné podpisy. Technickou hranicí je také limit 520 bajtů pro tento vložený skript; bajt je jednotka velikosti dat. Pro běžného čtenáře je hlavní rozlišit dvě kontroly: předkládáme správné pravidlo a zároveň máme to, co pravidlo požaduje. [3]

V roce 2015 Andresen předložil BIP 101 s návrhem postupně zvyšovat maximální velikost bloku. Dokument jej označuje jako hard fork: změnu, při níž by některé nově dovolené bloky starší pravidla odmítala. Registr vede tento návrh jako Closed, tedy uzavřený. Naproti tomu BIP 16 má stav Deployed, tedy nasazený. Už toto srovnání ukazuje, proč číslo BIP ani známé jméno autora nejsou důkazem aktivace. Čtete-li návrh, je vždy potřeba zjistit i to, zda se jeho pravidla skutečně začala používat. [4] [3]

Proč se o zvětšování bloků vedl spor? Větší blok může pojmout více transakcí, ale jeho data je třeba rozeslat, přijmout a ověřit. BIP 101 z roku 2015 proto probírá i náklady přenosu a riziko, že vyšší nároky zvýhodní velké provozovatele. Kdo má pomalé připojení, může být v jiné situaci než velká těžební firma. Autorova úvaha o budoucím vývoji technologií je argumentem pro návrh, nikoli naměřeným výsledkem pro všechny budoucí podmínky. Jde o hledání přijatelného kompromisu mezi kapacitou a možností síť samostatně ověřovat. [4]

Bitcoin.org vysvětluje, že vývojáři nemohou uživatelům vnutit změnu pravidel: lidé si volí software, který provozují. Aby spolu účastníci mohli fungovat, musí jejich pravidla zůstat slučitelná. Andresen mohl napsat návrh, připravit kód a přesvědčovat ostatní, ale nemohl jednostranně přepsat Bitcoin všem. Jeho práci má proto smysl hodnotit po jednotlivých příspěvcích: co služba umožnila, co kód dělal a co síť přijala. Dřívější zásluhy nejsou automatickým důkazem správnosti každého pozdějšího tvrzení. [5]

Pro nejúplnější obraz čtěte toto heslo společně s Laszlo Hanyecz, Amir Taaki, Satoshi Nakamoto. Opačným směrem na něj odkazují také Satoshi Nakamoto, Laszlo Hanyecz, Amir Taaki.

DOC · 001MIT Media Lab — MLTalks developer biographies (2015)Dokumentace DOC · 002Gavin Andresen — Original Bitcoin Faucet announcement and replies (2010)Dokumentace DOC · 003Gavin Andresen — BIP 16: Pay to Script HashDokumentace DOC · 004Gavin Andresen — BIP 101: Increase maximum block sizeDokumentace DOC · 005Bitcoin.org — About bitcoin.orgDokumentace
Revidováno: Primární zdroje · Nejde o investiční doporučení