CLTV

Anna navrhuje úschovu, v níž běžnou platbu schvalují společně s Petrem. Pro případ dlouhé nedostupnosti chce i záložní cestu použitelnou až za určenou hranicí. CLTV umí tuto časovou podmínku vložit do skriptu, tedy pravidel pro utracení dříve přijatých mincí. Samotné pole nLockTime by odložilo jen konkrétní transakci. CLTV brání obejít danou cestu novou transakcí s nižší hranicí. Jiné větve podmínky však mohou mít jiná pravidla. [1] [5]

CLTV nepoznává vlastníka a neposílá peníze. Pokud záložní cesta požaduje Annin podpis, musí jej Anna dodat i po splnění časové podmínky. Soukromý klíč je tajný číselný údaj, kterým se takový podpis vytváří. Ztracený soukromý klíč se uplynutím času neobnoví. Mince také automaticky nepřejdou na jinou adresu: někdo musí připravit, podepsat a odeslat platnou transakci. A pokud další větev dovoluje dřívější utracení, časový zámek v záložní větvi ji sám neomezuje. [1]

Blok sdružuje transakce do dávky, která se připojuje ke společné historii. CLTV se hodí pro podmínku navázanou na předem daný bod, nikoli pro požadavek „počkej určitý počet bloků od přijetí těchto mincí“. Druhou možnost řeší CSV spolu s BIP 68, pravidly relativního zámku. U něj záleží na potvrzení konkrétního výstupu, tedy dříve přijaté částky s podmínkami utracení. Ani jeden přístup nezaručuje přesné datum podle kalendáře: těžba kolísá a reorganizace může změnit potvrzenou historii. Při reorganizaci síť přijme jinou platnou větev řetězce a část dosavadních bloků přestane patřit do společné historie. [1] [7] [8] [9]

CLTV rozlišuje dva druhy údajů. Hodnota pod 500000000 znamená výšku bloku, jeho pořadí v řetězci. Od této hranice jde o časové razítko, tedy číselně zapsaný čas. Skriptová podmínka i pole nLockTime utrácející transakce musejí používat stejný druh. Nestačí tedy zjistit, že jedno číslo je větší než druhé: nemůžete porovnávat pořadové číslo bloku s časem, jako by měly stejný význam. [1] [3] [5]

Full Node, uzel samostatně kontrolující pravidla, ověří nezápornou hranici ze skriptu vůči absolutnímu nLockTime v transakci. Hranice nesmí být větší než nLockTime. Rovnost je pro tuto kontrolu v pořádku. Pak ale musejí projít i pravidla určující, zda lze transakci zařadit do konkrétního bloku. CLTV nečte hodiny vašeho počítače a nezastaví program, aby počkal do rána. Nesplněná kontrola znamená neplatný pokus o tuto cestu utracení. [1] [3] [4]

Vstup transakce ukazuje, které dříve přijaté mince se utrácejí. Má mimo jiné pole nSequence. U vstupu kontrolovaného CLTV nesmí mít hodnotu 0xffffffff, která označuje finální vstup. Kdyby ji měly všechny vstupy, bylo by možné časovou podmínku nLockTime vypnout. CLTV tomu zabrání tím, že příslušný vstup vyžaduje nefinální. Neznamená to ale, že automaticky nastaví konkrétní dobu relativního čekání; ta patří k jiným pravidlům. [1] [3] [4]

Vezměme modelovou transakci s nLockTime nastaveným na 900000 a nefinálním vstupem. Z hlediska této časové podmínky je nejdřívější možný blok 900001. Pravidlo zařazení totiž vyžaduje nLockTime přísně menší než výšku kandidátního bloku. Samotný blok 900000 proto nestačí, i když porovnání uvnitř CLTV dovolilo rovnost. „Finalita“ zde znamená způsobilost k zařazení, nikoli nevratnost platby. Poplatky, ostatní podmínky a rozhodnutí těžaře mohou potvrzení dál oddálit. [4]

Pro časové razítko se podle BIP 113 používá Median Time Past předchozího bloku. Jde o prostřední hodnotu seřazených časů posledních až 11 bloků, nikoli údaj z vašich hodinek nebo čas právě těženého bloku. Časové nLockTime musí být přísně menší než tato hodnota. Proto nelze slíbit, že peníze půjdou utratit přesně v místní poledne. Podmínka má síťově ověřitelný význam, ne funkci přesného rozvrhu plateb. [2] [4]

Při vyhodnocování pracuje skript se zásobníkem, pracovní hromádkou údajů. CLTV svůj časový argument pouze zkontroluje, ale neodstraní ho. V jednoduchém schématu proto po OP_CHECKLOCKTIMEVERIFY následuje OP_DROP, který jej odstraní; vloží se veřejný klíč a OP_CHECKSIG ověří podpis. Veřejný klíč slouží k ověřování podpisů a nemusí se držet v tajnosti. Tato posloupnost vysvětluje role instrukcí, není hotovým návodem k zamčení peněz. Musí odpovídat i verze skriptu, vstupní data a všechny další cesty utracení. [1] [3]

BIP 65 zavedl CLTV jako soft fork, zpřísnění pravidel, které nahradilo dřívější OP_NOP2. Nejde tedy jen o nápad na budoucí funkci. Přesto je třeba kontrolovat celý návrh: druh hranice, nLockTime, nSequence, podpisy i alternativní větve. Technické detaily lze ověřit v Bitcoin Core v29.0 a připojených specifikacích. Pro běžného uživatele je důležitá hlavně otázka, kdo smí peníze utratit před hranicí a po ní, a zda rozumí možnostem obnovy. [1] [3] [6] [10]