OP_CHECKTEMPLATEVERIFY

Анна хоче відкласти кошти, щоб пізніше розподілити їх між Петром і Євою. Вона не бажає покладатися лише на обіцянку того, хто зберігатиме гроші. У Bitcoin невитрачені кошти записані як виходи транзакцій, UTXO: кожен містить суму й умови її використання. CTV міг би додати до цих умов конкретний план розподілу. Під час витрачання виходу вузли — програми, які перевіряють правила мережі, — звіряли б нову транзакцію із цим планом. Інший отримувач або відхилення від визначеної суми не пройшли б перевірку. Автор пропозиції Jeremy Rubin описав її в BIP119; номер BIP було надано у 2020 році. [1] [3]

Шаблон визначає будову переказу: на скільки попередніх виходів посилаються входи та які нові виходи мають з’явитися. Для нових виходів він фіксує суми й скрипти, тобто умови майбутнього витрачання. Докладніше, BIP119 також охоплює версію транзакції; nLockTime — поле часових обмежень усієї транзакції; поля входів nSequence, які можуть впливати на часові блокування; та індекс входу, що перевіряється. Якщо якийсь scriptSig, вхідний скрипт із даними для витрачання, непорожній, додається й хеш усіх полів scriptSig. Отже, це не просто перелік отримувачів: зміна іншого охопленого поля також створить інший шаблон. Посилання на конкретні попередні монети та їхні суми — окреме питання, до якого повернемося нижче. [1]

Байт — звичайна одиниця обсягу даних. Запропонована перевірка використовує 32-байтовий хеш шаблону, обчислений за допомогою SHA256. Вузол обчислює такий самий відбиток транзакції, що витрачає вихід, і відхиляє невідповідність. Цифровий підпис підтверджує дозвіл на платіж за допомогою приватного ключа — секретного числового значення, яке при цьому не розкривається. Інша частина скрипту може вимагати підпису; CTV не замінює його в усіх випадках. Аргументи іншої довжини не виконують цієї перевірки й зарезервовані для майбутніх розширень, хоча політика ретрансляції може їх відхиляти. Неправильний аргумент сам собою не гарантує безпечного блокування. [1] [4] [12]

У наступному прикладі суми наведено в sats, найменших одиницях біткоїна. Хеш шаблону не містить безпосередньо outpoint, тобто посилань на конкретні UTXO, що витрачаються, або їхніх вхідних сум. Проте кількість входів фіксована. Припустімо, дозволений рівно один вхід, а виходи разом становлять 99 000 sats. Вхід на 100 000 sats залишає 1 000 sats комісії. Вхід, менший за суму виходів, не профінансує транзакцію. Більший вхід за незмінних виходів збільшить комісію, а не автоматично створить решту. [6] [9]

Шаблон може вимагати переходу до іншого виходу, скрипт якого містить затримку та шлях відновлення. Це дозволяє побудувати сховище з часом на реакцію на небажане виведення. Сам CTV не забезпечує всього захисту: важливі ключі, умови наступних виходів, спостереження й вчасне підтвердження відновлення. Деякі обмеження можна натомість підготувати заздалегідь підписаними транзакціями, але з іншими вимогами до співпраці та видалення ключів. [8] [5]

Блок об’єднує транзакції в пакет, який додають до спільної історії. У запропонованому керуванні перевантаженням спочатку підтверджується вихід, що зобов’язує розподілити кошти пізніше. Окремі виходи одержувачів можуть з’явитися в наступних транзакціях, наприклад за меншого навантаження. Одержувачам потрібні дані про план і можливість реалізувати своє право. Це не те саме, що звичайний платіж, уже підтверджений на їхню адресу, і не робить обмежений блок безмежним. [7] [11]

Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Анна може підготувати план задовго до публікації платежу, ще не знаючи майбутніх комісій. Фіксовані виходи не дозволяють довільно зменшити суму, що повертається в гаманець, і запропонувати різницю майнеру. Тому конструкція має передбачати спосіб додати комісію. Варіант — належно підготовлений CPFP: наступна транзакція витрачає вихід початкової та пропонує комісію, що спонукає майнера включити обидві. Інший варіант — шаблон, який від початку передбачає додатковий вхід. Його не можна просто додати до шаблону лише з одним входом. Mempool — набір непідтверджених транзакцій конкретного вузла; прийняття до нього ще не гарантує потрапляння в блок. [2] [6] [10]

Сам CTV перевіряє конкретний шаблон; це не універсальна мова для читання та довільного порівняння всіх даних транзакції. Він дозволяє готувати розгалужені плани майбутніх транзакцій, але його можливості не слід плутати із загальними рекурсивними Covenants. Комбінації з іншими запропонованими інструкціями можуть давати більше. Важливо з’ясувати, чи приклад використовує лише CTV, чи цілий пакет змін. [1] [2]

Під час перевірки 17 жовтня 2026 року BIP119 має статус Draft, тобто залишається пропозицією в розробці. Він надав би нову перевірну функцію OP_NOP4 — команді, яка зараз не має ефекту під час перевірки блока. Таке посилення спільних правил називається Soft Fork. Однак документ сам не визначає активацію. Публікація BIP не робить opcode реально застосовуваною командою; код, підтримка розробника чи демонстраційний гаманець також не доводять її застосування в основній мережі Bitcoin, mainnet. Тому для кожної демонстрації потрібно знати мережу, правила та інші пропозиції, від яких вона залежить. [1]

Доки правило не застосовується, його наявність у скрипті сама собою не захищає кошти: консенсус і відхилення в mempool різняться. Навіть за підтримки CTV єдиний обов’язковий шаблон без запасного шляху може замкнути недостатньо профінансований вихід. Новий малий внесок при цьому не блокує автоматично інші правильно профінансовані UTXO. Безпечний проєкт потребує перевірки сум, комісій, резервних копій і всіх шляхів відновлення. [1] [4] [6]