413 / 736HEARN

Mike Hearn

Vývojář bitcoinj a autor síťových a platebních návrhů

Mike Hearn pomáhal vyvíjet bitcoinj a navrhoval, jak mají peněženky komunikovat s uzly i obchodníky. Jeho práce ukazuje, co všechno se musí odehrát na pozadí obyčejné platby bitcoinem — a proč různé zprávy o jejím přijetí neznamenají totéž.

Mike Hearn je bitcoinový vývojář a spoluautor několika BIP, tedy dokumentů popisujících navrhovaná technická řešení. Podílel se na knihovně bitcoinj a na postupech pro kontrolu spojení, výběr potřebných transakcí a komunikaci při placení. Abychom jeho přínosu rozuměli, je užitečné sledovat cestu od telefonu s peněženkou až k obchodu, který čeká na platbu.

Když někdo vytváří bitcoinovou peněženku, nemusí psát veškerou komunikaci od začátku. Může použít knihovnu: soubor hotových funkcí, na kterých postaví vlastní aplikaci. Jednou z takových knihoven je bitcoinj. Její soubor AUTHORS uvádí Mika Hearna mezi mnoha přispěvateli a odkazuje na historii změn v systému Git. Tak lze dohledat konkrétní práci. Neznamená to, že Hearn sám napsal všechny funkce nebo že dnes celý projekt řídí. [1]

bitcoinj je knihovna v jazyce Java, se kterou lze spravovat peněženku a posílat či přijímat transakce bez místní instalace Bitcoin Core. Pro telefon je lákavý režim SPV, zkráceně Simplified Payment Verification: pracuje s hlavičkami bloků a transakcemi důležitými pro peněženku místo úplné kontroly všech transakcí. Šetří tím data a prostředky zařízení. Dokumentace uvádí také experimentální plné ověřování. Jde o různé režimy; lehčí provoz není stejná kontrola všech pravidel jen provedená rychleji. [2]

Představme si, že se notebook probudí ze spánku. Spojení s jiným uzlem může vypadat otevřeně, přesto už nefunguje. Hearnův BIP 31 umožňuje poslat ping s hodnotou nonce, zde číslem pro rozpoznání konkrétního dotazu. Protějšek stejné číslo vrátí ve zprávě pong. U verzí protokolu nad 60000 tak lze spojit dotaz s odpovědí a změřit dobu odezvy. Je to kontrola komunikace: samotná odpověď neprokazuje poctivost uzlu ani platnost platby. [3]

Další otázka zní: proč má telefon stahovat transakce, které se ho netýkají? BIP 37, jehož autory jsou Hearn a Matt Corallo, popisuje Bloom filtr — kompaktní pomůcku pro výběr možných shod. Pomocí filterload se nastaví, filteradd přidá údaj a filterclear jej odstraní. Filtr může propustit i nesouvisející transakci; tomu se říká falešná shoda. Přesnější výběr snižuje objem přenášených dat, ale protějšku může usnadnit propojení transakcí s IP adresou peněženky. Úspora dat tedy není automaticky ochranou soukromí. [4]

Telefon potřebuje poznat, zda přijatá transakce opravdu patří do určitého bloku. Zpráva merkleblock z BIP 37 mu poskytne podklady pro Merkleův důkaz: z několika otisků dat, tedy hashů, lze ověřit vazbu transakce na souhrnný otisk v hlavičce bloku. Nemusí kvůli tomu stáhnout celý blok. Důkaz ale neukáže, zda mu protějšek jiné transakce nezatajil. SPV také nenahrazuje úplné ověření jejich platnosti. Dokumentace bitcoinj vysvětluje, proč je nebezpečné, když útočník ovládne všechna spojení peněženky a vybírá, co jí ukáže. [4] [5]

Při nákupu potřebujete znát částku i příjemce. BIP 70, který napsali Gavin Andresen a Hearn, pro to zavádí PaymentRequest. Zpráva obsahuje platební podrobnosti: výstupy určující, kam má transakce prostředky přiřadit, částku a případně dobu platnosti požadavku. Totožnost obchodníka může být ověřena pomocí certifikátů X.509, podobně jako u webových serverů. Protokol ale umožňuje i pki_type none, tedy požadavek bez tohoto ověření. Samotný formát platební žádosti proto ještě nedokládá ověřenou totožnost obchodu. [6]

Pokud žádost uvádí platební server, peněženka mu po vašem odsouhlasení platby odešle zprávu Payment. Odpověď PaymentACK může říkat, že obchod platbu přijal ke zpracování. Z pohledu zákazníka je to užitečná informace, stále však pochází od serveru obchodníka. Není to důkaz potvrzení transakce v bloku. Podobně pole refund_to pouze sděluje, kam může obchod případně poslat peníze zpět; žádné vrácení samo neprovede. Komunikace o platbě a skutečný pohyb prostředků jsou dvě věci, které musí aplikace správně rozlišovat. [6]

Při čtení staršího návodu může vzniknout dojem, že popsaný postup musí fungovat všude. BIP 70 je v registru označen jako Deployed, tedy nasazený. Poznámky k Bitcoin Core 0.20.0 však zaznamenávají úplné odstranění jeho podpory z tohoto programu. Není v tom rozpor: historicky používaná specifikace nemusí být podporována každým dnešním klientem. Hearnova práce pomáhá pochopit vývoj peněženek; pro konkrétní použití je navíc potřeba ověřit možnosti konkrétního programu a jeho verze. [6] [7]

Pro nejúplnější obraz čtěte toto heslo společně s Jeff Garzik, Gloria Zhao, Merkle Tree. Opačným směrem na něj odkazují také Jeff Garzik, Gloria Zhao.

DOC · 001bitcoinj — recorded contributorsDokumentace DOC · 002bitcoinj — library and verification modesDokumentace DOC · 003BIP 31 — Pong messageDokumentace DOC · 004BIP 37 — connection Bloom filteringDokumentace DOC · 005bitcoinj — security modelDokumentace DOC · 006BIP 70 — Payment ProtocolDokumentace DOC · 007Bitcoin Core 0.20.0 — BIP70 removalDokumentace
Revidováno: Primární zdroje · Nejde o investiční doporučení