Peter Todd

Představte si, že potřebujete doložit, že určité znění smlouvy existovalo už před vznikem sporu. Právě takovou otázku řeší OpenTimestamps, projekt spojený s Peterem Toddem. Jeho historické oznámení z roku 2016 představovalo veřejnou zkušební verzi a obsahovalo poděkování za vývoj a testování, na nichž se podílel Riccardo Casatta. Je to doklad tehdejší spolupráce, nikoli tvrzení, že projekt zůstal ve zkušební fázi. Kromě důkazů o minulosti se Todd zabýval i podmínkami budoucího utrácení a nakládáním s platbou, která ještě není potvrzená. Začněme těmito dvěma oblastmi. [1]

Toddův BIP 65 zavedl OP_CHECKLOCKTIMEVERIFY, zkráceně CLTV. Je to instrukce, pomocí které lze určitou cestu k utracení bitcoinů podmínit dosažením výšky bloku nebo času. Představte si záložní cestu ke společným úsporám, kterou smí příjemce použít až později. Do té doby časová podmínka její použití blokuje. Jakmile je splněna, mince se samy neodešlou: stále je nutné vytvořit platnou transakci a splnit další požadavky, například dodat podpis. Pokud má úschova i jinou cestu utracení, ta se řídí vlastními podmínkami; zámek nelze automaticky vztáhnout na celý zůstatek. [2]

Časový zámek se neřídí jen hodinami na obrazovce peněženky. BIP 65 kontroluje vztah mezi požadavkem ve skriptu, tedy předpisu podmínek utracení, a polem nLockTime v transakci. Obě strany musí používat stejný druh hranice: výšku bloku, nebo čas. Vstup také nesmí mít pole nSequence nastavené na hodnotu označující konečnost, která by tuto kontrolu znemožnila. Jde o absolutní hranici, ne o měření relativního stáří výstupu od jeho potvrzení. Ani po splnění podmínek není slíbeno zařazení transakce do bloku v přesnou sekundu; k tomu je stále potřeba těžař a platný blok. [2]

Odeslaná transakce může zůstat v mempoolu, zásobníku nepotvrzených transakcí konkrétního uzlu. Když síť zdraží, odesílatel může chtít nabídnout vyšší poplatek prostřednictvím náhradní transakce. David A. Harding a Peter Todd popsali v BIP 125 původní pravidla takového nahrazování se signalizovaným souhlasem, označovaným opt-in. Signalizaci určovala hodnota nSequence; stav se mohl přenést i z nepotvrzeného předka, tedy z transakce, jejíž výstup další platba utrácí. Pravidla se tak netýkala jen jediné samostatné platby. Vyšší poplatek může pomoci, ale sám o sobě nezaručuje okamžité potvrzení. [3]

Nahrazení v mempoolu znamená změnu toho, co uzel uchovává jako kandidáta k potvrzení. Není to přepis potvrzené historie. BIP 125 zároveň popisuje historickou politiku opt-in, nikoli neměnný zákon pro všechny programy a jejich vydání. Pozdější Bitcoin Core přešel ke standardnímu nahrazování, které tento signál nevyžaduje; stále však uplatňuje pravidla pro přijetí náhrady. Pro příjemce z toho plyne jednoduché poučení: chybějící signál sám nedokazuje konečnost platby. A údaj „odesláno“ ještě neznamená, že transakce je v potvrzeném bloku. [3] [6]

Vraťme se ke smlouvě. OpenTimestamps vytváří ověřitelný důkaz, že konkrétní data existovala před doloženou časovou hranicí. Pracuje s hashem, krátkým digitálním otiskem obsahu, a s důkazem navázaným na Bitcoin. Změna dokumentu se při ověřování projeví jiným otiskem. Časové razítko ale samo nepotvrzuje autorství ani pravdivost tvrzení ve smlouvě. Někdo mohl včas opatřit razítkem i nepravdivý text. Rovněž nejde o zjištění přesného okamžiku vzniku souboru: důkaz omezuje, jak pozdě už daná data mohla vzniknout, neříká, jak dlouho předtím existovala. [1] [4]

Klient OpenTimestamps neposílá kalendářovým serverům samotný dokument. Zpracuje jeho otisk spolu s náhodnou hodnotou, aby server z obdržených dat nepoznal obsah. Kalendář je zde služba, která shromažďuje požadavky a pomáhá je navázat na Bitcoin. Ochrana obsahu však neznamená úplnou anonymitu: časové souvislosti nebo společně vytvořené důkazy mohou prozradit souvislost mezi požadavky. Vzniklý soubor .ots není zálohou dokumentu. Uchovejte jej společně s přesným původním souborem; z otisku nelze ztracený text obnovit a upravená kopie už představuje jiná data. [5]

Po vytvoření časového razítka nemusí být důkaz ještě navázán na potvrzený bitcoinový blok. Samotná existence souboru .ots proto ještě nepotvrzuje, že je vše hotovo. Klient OpenTimestamps rozlišuje čekající důkaz a úplný doklad, který obsahuje potřebnou cestu až k bloku. Příkaz ots upgrade může dostupné doplnění stáhnout a uložit do důkazu; nevynutí tím ale vytěžení bloku. Poté je třeba důkaz ověřit proti původním datům a bitcoinovému řetězci. Stejně jako u čekající platby je podstatný skutečný stav, nikoli jen to, že program vytvořil soubor nebo zobrazil oznámení. [5]