CSV

Anna a Petr mohou své společně uložené mince utratit dohodou. Chtějí však i záložní cestu, kterou Anna použije samostatně až po určitém čekání od potvrzení příslušného výstupu. CSV pomáhá tuto podmínku vynutit. Na rozdíl od CLTV, které míří na pevnou výšku nebo čas, není hranice předem jedním bodem v celé historii. Odvíjí se od konkrétních mincí. Založení peněženky, příprava podpisu ani dlouhé čekání nepotvrzené transakce tento začátek nenahrazují. Peněženka je aplikace nebo zařízení pro přijímání a odesílání bitcoinů. [1] [2] [8]

Blok sdružuje transakce do dávky, která se připojuje ke společné historii. Výška bloku je jeho pořadové číslo v řetězci. Představme si výstup potvrzený ve výšce 900000 a požadovanou blokovou prodlevu 10. Z hlediska tohoto zámku jej lze nejdříve utratit v bloku 900010. Při odstupu pouhých 9 bloků je ještě brzy. Nejde o příslib přesného počtu minut: bloky nevznikají v pravidelných rozestupech. A ani dostatečný odstup není potvrzením platby. Transakce musí být jinak platná a některý těžař ji musí do bloku skutečně zahrnout. [2] [4] [9]

Prodlevu lze zapsat také po 512 sekundách. Kód 2 pak představuje 1024 sekund. Neporovnávají se však dvoje hodiny na počítači. Začátkem je Median Time Past bloku před tím, který výstup potvrdil; na druhé straně je Median Time Past bloku před kandidátním blokem. Jde o prostřední čas z posledních až 11 bloků po jejich seřazení. Rozdíl těchto mediánů musí dosáhnout požadované prodlevy. Není to přesný budík podle místního času. [2] [4] [7]

Peněženka může pro platbu spojit více dříve přijatých částek. Každý vstup transakce odkazuje na dříve přijatý výstup, jehož stáří se odvozuje od potvrzení v řetězci. Samotný vstup pak obsahuje pole nSequence. To nese údaj, který se pro relativní čekání používá. Nestačí, že je dostatečně stará jen část peněz: musejí být splněny všechny použitelné zámky transakce. Reorganizace řetězce navíc může změnit místo potvrzení. Dřívější způsobilost k utracení proto není nevratnou vlastností mince. 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. [2] [4] [9]

Full Node, uzel ověřující pravidla samostatně, provede navazující kontroly. CSV podle BIP 112 porovná argument skriptu s nSequence příslušného vstupu utrácející transakce. Samo nepočítá stáří; to při ověřování transakce řeší BIP 68. U běžného argumentu bez vypínacího příznaku je potřeba verze transakce nejméně 2 a nenastavený bit 31 v nSequence. Bit je malý přepínač uvnitř číselného pole. Záporný argument, starší verze nebo neslučitelný nSequence způsobí selhání kontroly. [1] [2] [3]

Bit 22 určuje, jak prodlevu číst. Pokud není nastaven, jednotkou jsou bloky; pokud nastaven je, používají se kroky po 512 sekundách. Skriptový argument a nSequence musejí používat stejný druh. Je to podobné jako porovnávat vzdálenosti: větší číslo nestačí, pokud jedna strana počítá kilometry a druhá hodiny. V tomto případě se však nemíchají kilometry s časem, ale počet bloků s časovou prodlevou. [1] [2] [3]

Délku prodlevy nesou dolních 16 bitů. Maska 0x0000ffff je způsob, jak tuto část číselného pole vybrat. CSV při srovnání zohlední tuto část a typ prodlevy; nepovažuje libovolně velké nSequence automaticky za delší čekání. Po výběru příslušných bitů nesmí požadavek skriptu překročit hodnotu ve vstupu. Pro návrháře peněženky je to důležitá technická hranice, běžný uživatel ji ale nemá nastavovat ručně bez porozumění celému postupu. [1] [2] [3]

Nulová prodleva nepřidává čekání, ale ostatní kontroly běžného CSV stále platí. Jiný případ nastane, když nezáporný argument samotného skriptu obsahuje nastavený bit 31. Tehdy se CSV chová jako NOP, tedy instrukce bez účinku na relativní zámek. Takový argument nezajišťuje čekání. To je potřeba odlišit od stejného příznaku v nSequence vstupu: u běžného argumentu by tam nastavený být nesměl. [1] [3]

Pokud Annina záložní cesta potřebuje její podpis, musí jej dodat i po uplynutí prodlevy. Soukromý klíč je tajný číselný údaj, kterým se takový podpis vytváří. Ztracený soukromý klíč se nevrátí a jiná větev může stále dovolovat dřívější utracení. Při vykonání skriptu CSV ponechává argument na zásobníku, pracovní hromádce dat; často proto následuje OP_DROP, který jej odstraní. Samotné odstranění údaje ale nikoho neopravňuje k penězům. O tom rozhodují podpisové a další podmínky celého zvoleného postupu. [1] [3] [5]

BIP 112 zavedl CSV nahrazením OP_NOP3 spolu s pravidly BIP 68 a BIP 113. Je to aktivní možnost, nikoli jen plán. Používá se například v platebních kanálech Lightning Network, kde odklad může dát druhé straně prostor reagovat; sám však reakci nezařídí. Po splnění čekání je dál nutné transakci doručit a získat potvrzení. Záleží na poplatku, dostupných datech i stavu řetězce. Detaily ověřování popisuje Bitcoin Core v29.0 a uvedené specifikace. [1] [2] [6]