OP_CHECKTEMPLATEVERIFY

Anna chce odłożyć środki do późniejszego podziału między Piotra i Ewę. Nie chce opierać się wyłącznie na obietnicy osoby przechowującej pieniądze. W Bitcoinie niewydane środki są zapisane jako wyjścia transakcji, UTXO: każde zawiera kwotę i warunki jej użycia. CTV mogłoby dopisać do tych warunków konkretny plan podziału. Podczas wydawania wyjścia węzły, czyli programy sprawdzające reguły sieci, kontrolowałyby zgodność nowej transakcji z planem. Inny odbiorca lub kwota niezgodna z ustaleniami nie przeszłyby kontroli. Jeremy Rubin opisuje tę propozycję w BIP119, któremu numer BIP nadano w 2020 roku. [1] [3]

Szablon określa strukturę transferu: do ilu wcześniejszych wyjść odnoszą się wejścia i jakie nowe wyjścia mają powstać. Dla nowych wyjść ustala kwoty oraz skrypty, czyli warunki ich późniejszego wydawania. Dokładniej BIP119 obejmuje też wersję transakcji; nLockTime, pole ograniczeń czasowych całej transakcji; pola wejść nSequence, które mogą wpływać na blokady czasowe; oraz indeks aktualnie sprawdzanego wejścia. Jeśli jakikolwiek scriptSig, skrypt wejścia z danymi potrzebnymi do wydania, jest niepusty, dołącza się również hash wszystkich pól scriptSig. To zatem więcej niż lista odbiorców: zmiana innego uwzględnionego pola także daje inny szablon. Odwołania do konkretnych wcześniejszych monet i ich kwoty są osobnym zagadnieniem, wyjaśnionym poniżej. [1]

Bajt jest standardową jednostką ilości danych. Proponowana kontrola używa 32-bajtowego hasha szablonu obliczonego za pomocą SHA256. Węzeł oblicza ten sam odcisk transakcji wydającej wyjście i odrzuca niezgodność. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Inna część skryptu może wymagać podpisu; CTV nie zastępuje go we wszystkich przypadkach. Argumenty innej długości nie uruchamiają tej kontroli i są zarezerwowane dla przyszłych rozszerzeń, choć polityka przekazywania może je odrzucać. Błędny argument nie oznacza więc automatycznie bezpiecznego zablokowania monet. [1] [4] [12]

W następnym przykładzie kwoty podajemy w sats, najmniejszych jednostkach bitcoina. Hash szablonu nie zawiera bezpośrednio outpointów, czyli odwołań do konkretnych wydawanych UTXO, ani ich kwot wejściowych. Liczba wejść pozostaje jednak ustalona. Załóżmy dokładnie jedno dozwolone wejście i wyjścia o łącznej wartości 99 000 sats. Wejście o wartości 100 000 sats pozostawi 1 000 sats opłaty. Wejście mniejsze od sumy wyjść nie sfinansuje transakcji. Większe przy tych samych wyjściach zwiększy opłatę, zamiast automatycznie tworzyć resztę. [6] [9]

Szablon może nakazywać przejście do kolejnego wyjścia ze skryptem zawierającym opóźnienie i ścieżkę ratunkową. Pozwala to zbudować skarbiec z czasem na reakcję na niepożądaną wypłatę. CTV nie jest jednak całym zabezpieczeniem: liczą się klucze, warunki kolejnych wyjść, monitorowanie i potwierdzenie odzyskania środków na czas. Niektóre ograniczenia można przygotować wcześniej podpisanymi transakcjami, lecz wymaga to innej współpracy i usuwania kluczy. [8] [5]

Blok grupuje transakcje w pakiet dołączany do wspólnej historii. W proponowanym sterowaniu przeciążeniem najpierw potwierdza się wyjście zobowiązujące do późniejszego rozdzielenia środków. Osobne wyjścia odbiorców mogą powstać w kolejnych transakcjach, choćby przy mniejszym ruchu. Odbiorcy potrzebują danych o planie i możliwości wyegzekwowania swojego prawa. Nie jest to zwykła płatność już potwierdzona na ich adres i nie tworzy nieskończonego miejsca w ograniczonym bloku. [7] [11]

Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Anna może przygotować plan długo przed publikacją płatności, nie znając jeszcze przyszłych opłat. Stałe wyjścia nie pozwalają jej dowolnie zmniejszyć kwoty wracającej do portfela i zaoferować różnicy górnikowi. Konstrukcja musi więc przewidywać sposób dodania opłaty. Jedną z możliwości jest odpowiednio przygotowane CPFP: kolejna transakcja wydaje wyjście pierwotnej i oferuje opłatę zachęcającą górnika do uwzględnienia obu. Inną jest szablon przewidujący dodatkowe wejście od samego początku. Nie można go po prostu dodać do szablonu dopuszczającego tylko jedno wejście. Mempool to zbiór niepotwierdzonych transakcji konkretnego węzła; przyjęcie do niego nie gwarantuje jeszcze miejsca w bloku. [2] [6] [10]

Sam CTV sprawdza konkretny szablon; nie jest ogólnym językiem do odczytu i dowolnego porównywania wszystkich danych transakcji. Pozwala przygotować rozgałęzione plany przyszłych transakcji, ale nie należy utożsamiać go z ogólnymi rekurencyjnymi Covenants. Połączenia z innymi proponowanymi instrukcjami mogą dawać więcej możliwości. Trzeba więc sprawdzić, czy przykład używa samego CTV, czy całego pakietu zmian. [1] [2]

Podczas kontroli 17 października 2026 roku BIP119 ma status Draft, czyli nadal jest opracowywaną propozycją. Nadawałby nową funkcję kontrolną OP_NOP4, instrukcji obecnie bez wpływu na weryfikację bloku. Takie zaostrzenie wspólnych reguł nazywa się Soft Fork. Dokument nie ustala jednak sam aktywacji. Opublikowanie BIP nie zmienia opcode w faktycznie egzekwowaną instrukcję; kod, poparcie programisty czy portfel demonstracyjny również nie dowodzą jej stosowania w głównej sieci Bitcoina, mainnet. Przy każdej demonstracji trzeba więc ustalić sieć, reguły i inne propozycje, od których zależy. [1]

Dopóki reguła nie jest egzekwowana, samo umieszczenie jej w skrypcie nie zapewnia ochrony: konsensus i odrzucenie przez mempool to różne rzeczy. Nawet przy obsłudze CTV jeden obowiązkowy szablon bez drogi wyjścia może uwięzić niedofinansowane wyjście. Nowa mała wpłata nie blokuje automatycznie innych poprawnie sfinansowanych UTXO. Bezpieczny projekt wymaga sprawdzenia kwot, opłat, kopii zapasowych i wszystkich ścieżek odzyskania środków. [1] [4] [6]