Timelock si představ jako pravidlo „touto cestou můžeš peníze utratit až později“. Může odkazovat na určitou výšku bloku, tedy jeho pořadí v řetězci, čas odvozený z řetězce nebo dobu od potvrzení konkrétního výstupu. Výstup je částka s pravidly, kdo a za jakých podmínek ji smí utratit. Čekání nenahrazuje podpis ani ostatní podmínky a samo peníze nikam nepošle. Záleží také na tom, zda čas omezuje jen jednu připravenou transakci, nebo je vynucen přímo v pravidlech utracení peněz.
Anna a Pavel si mohou nastavit společné prostředky tak, že je společně utratí kdykoli, ale Anna je sama získá až po určité prodlevě. Když Pavel přestane reagovat, odložená větev nabídne předem dohodnutou cestu zpět. Větev zde znamená jednu z povolených možností utracení; každá může mít jiné podmínky. Zámek proto nemusí blokovat všechny možnosti současně. Pravidla musejí být součástí výstupu už při jeho vytvoření. Nestačí později přidat do běžné peněženky poznámku „odemknout za týden“. Anna bude i po čekání potřebovat příslušný klíč a údaje potřebné k sestavení platné transakce. Timelock pomáhá řídit přístup, neumí obnovit ztracené klíče. [3]
Absolutní zámek se vztahuje k pevné hranici, kterou transakce zapisuje do údaje nLockTime. Má-li transakce účinné nLockTime nastavené na výšku 1 000 000, může tuto podmínku splnit nejdříve v bloku 1 000 001: rovnost ještě nestačí. Relativní zámek naopak měří prodlevu od potvrzení utráceného výstupu. Pokud Annin výstup vznikne v bloku 1 000 000 a příslušná větev vyžaduje prodlevu 6 bloků, jeho utracení může splnit tuto podmínku nejdříve v bloku 1 000 006. Uvedená čísla jsou příklady, ne aktuální výška sítě. Podmínky podpisů, ostatních vstupů a případné další zámky platí dál. Šest bloků také není přesně hodina: bloky přicházejí v nepravidelných rozestupech. Relativní čekání nezačíná vytvořením peněženky ani okamžikem, kdy se Anna rozhodne peníze použít. [1] [2] [5]
Představ si, že Anně právě uplynula požadovaná prodleva. Síť za ni nezačne jednat. Někdo stále musí vytvořit nebo použít připravenou transakci, dodat podpisy, zaplatit poplatek a předat ji síti. Teprve pak ji může těžař zařadit do bloku. Splněný Timelock je jedna splněná podmínka, ne rezervace místa ani automatický převod. Obvykle stanoví začátek možnosti utratit, nikoli okamžik, kdy tato možnost sama zanikne. Při reorganizaci se část řetězce nahradí jinou platnou větví. To může změnit potvrzení výstupu i počítání relativní prodlevy. Při vlastní konstrukci je potřeba předem ověřit všechny větve, podporu peněženky a zálohu klíčů i pravidel utracení; čas chybně nastavenou podmínku neopraví. [2] [5]
U časových podmínek se používá Median Time Past, zkráceně MTP. Pro posuzovaný blok jde o medián časových značek posledních 11 bloků končících předchozím blokem. Seřaď jejich časy a vezmi prostřední, tedy šestý: to je medián. Není to aritmetický průměr. Pravidlo popisuje BIP113 a Bitcoin Core pro tento výpočet používá GetMedianTimePast. Rozhodný čas tedy není aktuální čas v Annině telefonu ani časová značka právě navrhovaného bloku. Půlnoc v kalendáři nemusí být chvílí, kdy je časový zámek splněn. Zámky podle výšky se zase řídí pořadím bloků v řetězci; neodpočítávají sekundy. [4]
Teď lze rozlišit čtyři názvy, které v dokumentaci potkáš. nLockTime je údaj v celé transakci pro absolutní hranici. Relativní prodlevu nese nSequence u vstupu podle BIP68. Samotné nLockTime ale nezamkne UTXO, tedy dosud neutracený výstup, proti jiné transakci s jiným nastavením. Kdo smí peníze utratit, může takovou jinou transakci vytvořit, pokud mu v tom nebrání pravidla výstupu. Bitcoin Script je jazyk, kterým se tato pravidla utracení zapisují. Příkaz OP_CHECKLOCKTIMEVERIFY, zkráceně CLTV podle BIP65, v použité větvi vyžaduje odpovídající absolutní nastavení. OP_CHECKSEQUENCEVERIFY, tedy CSV podle BIP112, hlídá relativní nastavení, jehož skutečnou prodlevu kontroluje BIP68. CLTV ani CSV neodešlou peníze a nepřidají chybějící podpis. Jiná povolená větev může být použitelná za jiných podmínek. [1] [2] [3]
Následující části jsou technická reference. Pole znamená položku uloženou v transakci; vstup odkazuje na výstup, který se utrácí. nSequence je údaj u každého vstupu. Jeho zvláštní hodnota může vypnout účinek nLockTime, proto samotné vyplnění data nestačí. nLockTime je nezáporné 32bitové pole; nula vypíná absolutní časovou podmínku. Jsou-li všechny vstupy nastavené na SEQUENCE_FINAL s hodnotou 0xffffffff, nesplněné nLockTime se ignoruje. Pro účinný absolutní zámek musí mít alespoň jeden vstup jinou hodnotu nSequence. Hodnotí se tato konkrétní transakce, nikoli trvalé zmrazení jejích vstupů. [5] [7]
Stejné pole umí vyjadřovat dvě různé věci, proto je musí oddělovat číselný práh. Unix timestamp je číselný zápis času v sekundách od začátku roku 1970 v UTC. Kandidátní blok je blok, do něhož by se právě ověřovaná transakce měla zařadit. LOCKTIME_THRESHOLD má hodnotu 500000000. Nižší nLockTime znamená výšku bloku, stejná nebo vyšší hodnota Unix timestamp. Při zapnuté absolutní kontrole musí být nLockTime přísně menší než výška kandidátního bloku nebo rozhodný MTP. Rovnost nestačí; nejde o částku, průměrnou výšku ani datum aktivace protokolu. [5] [8]
Operand je hodnota předaná příkazu; opcode je samotný příkaz Scriptu. CLTV porovnává požadavek uložený ve větvi s nastavením transakce. Zda už řetězec došel dost daleko, ověřuje další kontrola. Proto nejde jen o porovnání dnešního data s jedním číslem. OP_CHECKLOCKTIMEVERIFY vyžaduje nezáporný operand, stejný typ výška/čas jako nLockTime a operand nejvýše rovný nLockTime. Příslušný utrácející vstup nesmí mít nSequence 0xffffffff. Opcode přímo nečte hodiny ani výšku řetězce; nastavení transakce se ověřuje odděleně při kontrole její časové platnosti. Ostatní podmínky Scriptu zůstávají nutné. [1] [6]
Číselný údaj nSequence obsahuje nejen délku čekání, ale i přepínače určující jeho význam. Bit je jedna nula nebo jednička v tomto zápisu; jeho nastavení může zapnout určitou možnost. Následující pozice bitů jsou součástí technického formátu, ne počty potvrzení. U transakcí verze 2 nebo vyšší zapíná BIP68 relativní podmínku pro vstupy bez nastaveného bitu 31. Spodních 16 bitů určuje prodlevu; bit 22 volí jednotky 512 sekund, jinak bloky. Bloková prodleva se počítá od výšky potvrzení utráceného výstupu. Časová od MTP bloku před jeho potvrzením do MTP před kandidátním blokem. Nejde o dobu od vytvoření transakce v peněžence. [2] [5]
CSV používá podobnou kontrolu pro relativní čekání. Maska vybírá příslušné bity nSequence a disable flag je přepínač vypnutí. Lightning Network je síť platebních kanálů: účastníci v nich průběžně mění dohodnuté rozdělení společně uzamčených peněz. Zpoždění dává druhé straně čas reagovat, pokud někdo zveřejní starý, již odvolaný stav. Commitment transaction zachycuje rozdělení peněz; revokační klíč dovoluje druhé straně utratit příslušný výstup odvolané verze trestnou větví. OP_CHECKSEQUENCEVERIFY s aktivním nezáporným operandem vyžaduje verzi alespoň 2, vypnutý disable flag vstupu, shodný typ prodlevy a dostatečnou hodnotu nSequence po použití masky. Skutečné stáří zvlášť vynucuje BIP68. CSV dovoluje odloženou obnovovací větev. U Lightning výstupu to_local prodleva to_self_delay omezuje vlastníka commitment transakce; druhá strana se správným revokačním klíčem může použít trestnou větev bez této prodlevy. [3] [9]
Dvě téměř stejná čísla mohou mít rozdílný účinek. Níže uvedené hodnoty začínající 0x jsou zapsané v šestnáctkové soustavě. NOP označuje instrukci, která zde nepřidá časové omezení. Důležité je také to, zda je přepínač ve vstupu transakce, nebo v hodnotě předané CSV. Bit 31 je SEQUENCE_LOCKTIME_DISABLE_FLAG a vypíná relativní interpretaci BIP68 pouze pro daný vstup. Hodnota 0xfffffffe jej obsahuje, ale není SEQUENCE_FINAL: dovoluje účinné nLockTime a CLTV. Hodnota 0xffffffff je final. Nezáporný operand CSV s nastaveným disable flagem se chová jako NOP; nastavený flag ve vstupu však aktivní požadavek CSV nesplní. Tyto dva případy se nesmějí zaměňovat. [3] [7]
RPC je příkaz pro práci s vlastním uzlem, tedy programem, který ověřuje bitcoinové bloky a transakce. Dekódování pouze přeloží uložené údaje do čitelného výpisu; kontrolní příkaz pak zkusí, zda by konkrétní podepsaná transakce prošla. Mempool je místní seznam čekajících transakcí u daného uzlu. RPC decoderawtransaction v Core 31 ukáže version, locktime a sequence jednotlivých vstupů. Pro CLTV/CSV zkontroluj skutečně použitý Script a utrácený výstup; samotné dekódování není důkaz platnosti. RPC testmempoolaccept testuje podepsaného kandidáta vůči současnému řetězci, pravidlům platnosti Bitcoinu a místním pravidlům uzlu pro přijetí transakcí, bez přijetí do mempoolu a bez odvysílání. Zkontroluj allowed a důvod odmítnutí; úspěch není příslib budoucího potvrzení. [10] [11] [12]
Pro nejúplnější obraz čtěte toto heslo společně s CLTV, CSV, Lightning Network, Payment Channel, Transakce, Bitcoin Script. Opačným směrem na něj odkazují také Potvrzení, Bitcoin Script, HTLC, CLTV.