Уяви Timelock як правило «цим шляхом — лише пізніше». Воно може спиратися на певну висоту блоку, тобто його порядковий номер у ланцюгу, час із ланцюга або затримку від підтвердження конкретного виходу. Вихід — це сума з правилами, хто й за яких умов може її витратити. Очікування не замінює підпису чи інших вимог і саме нікуди не надсилає грошей. Також важливо, чи час обмежує лише одну підготовлену транзакцію, чи його вимагають правила витрачання самих коштів.
Анна й Павел можуть налаштувати спільні кошти так, щоб витрачати їх разом будь-коли, а Анна сама — лише після затримки. Якщо Павел перестане відповідати, відкладена гілка надасть заздалегідь погоджений шлях повернення. Гілка тут означає один із дозволених способів витрачання; кожен може мати свої умови. Тому блокування не обов’язково закриває всі можливості одночасно. Правила мають бути частиною виходу вже під час його створення. Недостатньо потім додати у звичайному гаманці примітку «розблокувати за тиждень». Навіть після очікування Анні потрібні відповідний ключ і дані для побудови дійсної транзакції. Timelock керує доступом, але не відновлює втрачені ключі. [3]
Абсолютне блокування задає фіксовану межу, записану в полі nLockTime транзакції. Якщо дієвий nLockTime транзакції дорівнює висоті 1 000 000, перший блок, що може виконати цю умову, — 1 000 001: рівності ще недостатньо. Відносне блокування натомість рахує затримку від підтвердження виходу, що витрачається. Якщо вихід Анни створено в блоці 1 000 000, а відповідна гілка вимагає затримки 6 блоків, його витрачання може виконати цю умову найраніше в блоці 1 000 006. Це приклади чисел, а не поточна висота мережі. Умови підписів, інших входів та можливі додаткові блокування залишаються чинними. Шість блоків — також не рівно година: вони з’являються через нерівні проміжки. Відносне очікування починається не зі створення гаманця й не з моменту, коли Анна вирішила скористатися коштами. [1] [2] [5]
Припустімо, потрібна затримка Анни щойно минула. Мережа не почне діяти замість неї. Хтось усе ще має створити транзакцію або використати підготовлену, надати підписи, сплатити комісію й передати її мережі. Лише тоді майнер може включити її до блоку. Виконаний Timelock — одна виконана умова, а не бронювання місця чи автоматичний переказ. Зазвичай він визначає початок можливості витратити, а не момент її автоматичного закінчення. Під час реорганізації частина ланцюга замінюється іншою дійсною гілкою. Це може змінити підтвердження виходу та розрахунок відносної затримки. Для власної конструкції треба заздалегідь перевірити всі гілки, підтримку з боку гаманця й резервні копії ключів та правил витрачання: час не виправить неправильно задану умову. [2] [5]
Часові умови використовують Median Time Past, скорочено MTP. Для блоку, що перевіряється, це медіана часових міток останніх 11 блоків, завершуючи попереднім. Відсортуй їхні часи й візьми середній за позицією, шостий: це медіана, а не середнє арифметичне. Правило описує BIP113, а Bitcoin Core застосовує GetMedianTimePast. Отже, вирішальним є не поточний час телефона Анни й не часова мітка запропонованого блоку. Північ за календарем не обов’язково збігається з виконанням блокування. Умови за висотою чекають на блоки, а не відлічують секунди. [4]
Тепер можна розрізнити чотири назви з документації. nLockTime — поле всієї транзакції для абсолютної межі. nSequence у вході містить відносну затримку за BIP68. Але сам nLockTime не блокує UTXO, тобто ще не витрачений вихід, від іншої транзакції з іншими налаштуваннями. Той, хто має право витрачати, може створити таку транзакцію, якщо правила виходу не заважають. Bitcoin Script — мова, якою записують ці правила витрачання. Команда OP_CHECKLOCKTIMEVERIFY, або CLTV за BIP65, вимагає відповідного абсолютного налаштування у вибраній гілці. OP_CHECKSEQUENCEVERIFY, або CSV за BIP112, перевіряє відносне налаштування, а фактичну затримку вимагає BIP68. Ні CLTV, ні CSV не надсилають коштів і не додають відсутнього підпису. Інша дозволена гілка може працювати за інших умов. [1] [2] [3]
Наступні розділи — технічний довідник. Поле означає дані, збережені в транзакції; вхід посилається на вихід, що витрачається. Кожен вхід має nSequence. Особливе значення може вимкнути дію nLockTime, тому просто вказати дату недостатньо. nLockTime — беззнакове 32-бітове поле; нуль вимикає абсолютну часову умову. Якщо всі входи мають SEQUENCE_FINAL зі значенням 0xffffffff, невиконаний nLockTime ігнорується. Для дієвого абсолютного блокування принаймні один вхід повинен мати інше значення nSequence. Оцінюється саме ця транзакція, а не постійне заморожування її входів. [5] [7]
Одне поле може виражати дві різні речі, які розділяє числовий поріг. Unix timestamp — запис часу в секундах від початку 1970 року за UTC. Кандидатний блок — той, до якого мала б увійти транзакція, що перевіряється. LOCKTIME_THRESHOLD дорівнює 500000000. Менший nLockTime означає висоту блоку, рівний або більший — Unix timestamp. За ввімкненої абсолютної перевірки nLockTime має бути строго меншим за висоту кандидатного блоку або відповідний MTP. Рівності недостатньо; це не сума, середня висота чи дата активації протоколу. [5] [8]
Операнд — значення, передане команді; opcode — сама команда Script. CLTV порівнює вимогу гілки з налаштуванням транзакції. Чи достатньо просунувся ланцюг, визначає окрема перевірка. Це більше, ніж просто порівняння сьогоднішньої дати з числом. OP_CHECKLOCKTIMEVERIFY вимагає невід’ємного операнда, такого самого типу висота/час, як nLockTime, і значення не більшого за nLockTime. Відповідний вхід витрачання не може мати nSequence 0xffffffff. Opcode не читає годинник або висоту ланцюга безпосередньо; налаштування транзакції перевіряються окремо під час оцінки її часової чинності. Решта умов Script залишаються обов’язковими. [1] [6]
Число nSequence містить і тривалість очікування, і перемикачі його значення. Біт — нуль або одиниця в цьому записі; його встановлення може ввімкнути певну можливість. Наведені далі позиції бітів — частина формату, а не кількість підтверджень. Для транзакцій версії 2 або вище BIP68 вмикає відносну умову для входів без установленого біта 31. Нижні 16 бітів задають затримку; біт 22 обирає одиниці по 512 секунд, інакше використовуються блоки. Блокова затримка рахується від висоти підтвердження виходу, що витрачається. Часова — від MTP блоку перед його підтвердженням до MTP перед кандидатним блоком. Це не час від створення транзакції в гаманці. [2] [5]
CSV робить схожу перевірку для відносного очікування. Маска вибирає відповідні біти nSequence, а disable flag — перемикач вимкнення. Lightning Network — мережа платіжних каналів: учасники оновлюють узгоджений розподіл спільно заблокованих коштів. Затримка дає іншій стороні час відреагувати, якщо хтось опублікує старий, уже відкликаний стан. Commitment transaction фіксує розподіл коштів; ключ відкликання дозволяє іншій стороні витратити відповідний вихід відкликаної версії через штрафну гілку. OP_CHECKSEQUENCEVERIFY з активним невід’ємним операндом вимагає версії щонайменше 2, невстановленого disable flag входу, однакового типу затримки та достатнього значення nSequence після застосування маски. Фактичний вік окремо перевіряє BIP68. CSV дозволяє відкладену гілку відновлення. У виході Lightning to_local затримка to_self_delay обмежує власника commitment transaction; інша сторона з правильним ключем відкликання може використати штрафну гілку без цієї затримки. [3] [9]
Два майже однакові числа можуть діяти по-різному. Наведені значення з 0x записано шістнадцятково. NOP означає команду, що тут не додає часової вимоги. Важливо й те, де перемикач: у вході транзакції чи у значенні, переданому CSV. Біт 31 — це SEQUENCE_LOCKTIME_DISABLE_FLAG; він вимикає відносну інтерпретацію BIP68 лише для цього входу. Значення 0xfffffffe містить його, але не є SEQUENCE_FINAL: воно дозволяє дієві nLockTime і CLTV. Значення 0xffffffff є final. Невід’ємний операнд CSV з установленим disable flag поводиться як NOP; натомість такий flag у вході не задовольняє активну вимогу CSV. Ці два випадки не можна плутати. [3] [7]
RPC — команда для роботи з власним вузлом, тобто програмою, яка перевіряє блоки й транзакції Біткоїна. Декодування лише перетворює збережені дані на читабельний список; тестова команда перевіряє, чи пройшла б конкретна підписана транзакція. Mempool — місцевий список транзакцій, що очікують у вузлі. RPC decoderawtransaction у Core 31 показує version, locktime та sequence кожного входу. Для CLTV/CSV перевір фактично використаний Script і вихід, що витрачається; саме декодування не доводить чинності. RPC testmempoolaccept перевіряє підписаного кандидата щодо поточного ланцюга, правил дійсності Біткоїна та місцевих правил приймання транзакцій вузлом, без прийняття до mempool і без трансляції. Перевір allowed і причину відмови; успіх не обіцяє майбутнього підтвердження. [10] [11] [12]
Для повної картини прочитайте також CLTV, CSV, Lightning Network, Payment Channel, Транзакція, Bitcoin Script. На цю статтю також посилаються Підтвердження, Bitcoin Script, HTLC, CLTV.