OP_CHECKTEMPLATEVERIFY

Anna chce připravit prostředky, které se později rozdělí mezi Petra a Evu. Nechce se přitom spoléhat jen na slib někoho, kdo peníze drží. V Bitcoinu jsou neutracené prostředky zapsány jako výstupy transakcí, označované UTXO: každý nese částku a podmínky, za kterých ji lze použít. CTV by do těchto podmínek mohl vložit konkrétní plán dalšího rozdělení. Až by někdo výstup utrácel, uzly, tedy programy ověřující pravidla sítě, by zkontrolovaly, zda nová transakce plán dodržuje. Jiný příjemce nebo jiná předepsaná částka by kontrolou neprošly. Autorem dokumentu BIP119 s tímto návrhem je Jeremy Rubin; číslo BIP mu bylo přiděleno v roce 2020. [1] [3]

Šablona určuje uspořádání převodu: na kolik dřívějších výstupů budou odkazovat vstupy a jaké nové výstupy mají vzniknout. U nových výstupů fixuje částky i skripty, tedy podmínky jejich dalšího utracení. Podrobněji BIP119 zahrnuje také verzi transakce, nLockTime jako údaj pro časové omezení celé transakce, pole vstupů nSequence, která mohou ovlivňovat časové zámky, a pořadový index právě kontrolovaného vstupu. Pokud je některý scriptSig, vstupní skript s údaji k utracení, neprázdný, přidává se také hash všech polí scriptSig. Nejde tedy jen o seznam příjemců: i změna jiného zahrnutého údaje by znamenala jinou šablonu. Odkazy na konkrétní starší mince a jejich částky jsou samostatná otázka, ke které se dostaneme níže. [1]

Bajt je běžná jednotka množství dat. Navrhovaná kontrola používá 32bajtový otisk vypočtený pomocí SHA256. Uzel sestaví tentýž otisk z transakce, která výstup právě utrácí, a při neshodě ji odmítne. Digitální podpis dokládá oprávnění k platbě pomocí soukromého klíče, tajného číselného údaje, aniž by jej odhalil. Podpis může požadovat další část skriptu; CTV sám jej nenahrazuje všude. Jiné délky argumentu tuto kontrolu neprovádějí a jsou vyhrazené pro budoucí rozšíření; síťová politika je přitom může odmítnout. Chybný argument tedy automaticky neznamená bezpečné uzamčení mincí. [1] [4] [12]

V následujícím příkladu používáme sats, nejmenší bitcoinové jednotky. Otisk šablony přímo neobsahuje outpointy, tedy odkazy na konkrétní utrácené UTXO, ani jejich vstupní částky. Počet vstupů přesto určený je. Představte si jediný povolený vstup a součet výstupů 99 000 sats. Vstup 100 000 sats ponechá 1 000 sats jako poplatek. Vstup menší než součet výstupů takovou transakci nezaplatí. Vyšší vstup při stejných výstupech naopak zvětší poplatek, nikoli automaticky vrácené peníze. [6] [9]

Šablona může předepsat přechod do dalšího výstupu, jehož skript obsahuje prodlevu a záchrannou cestu. To umožňuje skládat trezor s časem na reakci na nežádoucí výběr. CTV sám ale není celé zabezpečení: záleží na klíčích, podmínkách dalších výstupů, monitorování a včasném potvrzení obnovy. Část omezení lze místo toho připravit předem podepsanými transakcemi, avšak s jinými nároky na spolupráci a mazání klíčů. [8] [5]

Blok sdružuje transakce do dávky, která se připojuje ke společné historii. U navrhovaného řízení zahlcení se nejprve potvrdí výstup zavazující prostředky k pozdějšímu rozdělení. Jednotlivé výstupy pro příjemce mohou vzniknout až v navazujících transakcích, třeba při menším vytížení sítě. Příjemci potřebují údaje o tomto plánu a možnost své právo uplatnit. Není to totéž jako již potvrzená běžná platba na jejich adresu a nedělá to z omezeného bloku nekonečný prostor. [7] [11]

Peněženka je aplikace nebo zařízení pro přijímání a odesílání bitcoinů. Anna může plán připravit dlouho před tím, než bude potřeba platbu zveřejnit. Tou dobou ale nezná budoucí poplatky. Pevné výstupy jí nedovolují libovolně ubrat z částky vracené do peněženky a rozdíl nabídnout těžaři. Konstrukce proto musí mít způsob, jak poplatek doplnit. Možností je vhodně připravený CPFP: navazující transakce utratí výstup původní transakce a nabídne takový poplatek, aby těžaře motivovala zahrnout obě. Jinou možností je šablona, která už předem počítá s dalším vstupem. Ten nelze dodatečně přidat k šabloně určené pro jediný vstup. Mempool je zásobník nepotvrzených transakcí daného uzlu; přijetí do něj ještě nezaručuje zařazení do bloku. [2] [6] [10]

Samotný CTV kontroluje konkrétní šablonu; není obecným jazykem pro čtení a libovolné porovnávání všech údajů transakce. Lze s ním připravovat větvené plány více budoucích transakcí, ale jeho možnosti se nesmějí zaměňovat s obecnými rekurzivními Covenants. Kombinace s dalšími navrhovanými instrukcemi mohou umět víc. Je proto nutné sledovat, zda ukázka používá pouze CTV, nebo celý balík změn. [1] [2]

Při kontrole 17. října 2026 má BIP119 stav Draft, tedy rozpracovaný návrh. Počítá s tím, že OP_NOP4, příkaz dnes bez účinku při ověřování bloku, dostane novou kontrolní funkci. Takové zpřísnění společných pravidel se označuje Soft Fork. Dokument ale sám neurčuje aktivaci. Samotné zveřejnění BIP neznamená aktivní opcode, tedy skutečně vynucovaný příkaz; ani kód, podpora vývojáře či ukázková peněženka nedokazují jeho vynucování na hlavní bitcoinové síti, mainnetu. U každé demonstrace je proto důležité znát použitou síť, pravidla a případné další návrhy, na kterých závisí. [1]

Dokud se pravidlo nevynucuje, nelze na jeho ochranu spoléhat jen proto, že jej skript obsahuje; konsenzus a odmítnutí mempoolem nejsou totéž. I v prostředí s podporou CTV může jediná povolená šablona bez únikové cesty uvěznit podfinancovaný výstup. Nový malý vklad přitom automaticky nezablokuje jiné již správně financované UTXO. Bezpečný návrh potřebuje kontrolu částek, poplatků, záloh a všech cest obnovy. [1] [4] [6]