Point Time Locked Contract поєднує точкове блокування з часовим шляхом повернення: завершення adaptor signature розкриває відповідний скаляр, яким попередній учасник завершує власний підпис, а після спливу timelock кошти можна повернути; це складова протоколу, а не стандартний сьогодні тип платежу Lightning.
HTLC ставить успішну гілку в залежність від знання прообразу спільного хешу; PTLC натомість використовує точку T = t·G та adaptor signature, яку можна завершити лише зі скаляром t. Часова гілка зберігається: якщо розрахунок не відбувся, сторона-відправник повертає кошти після timeout. [1]
Одержувач обирає таємний скаляр і публікує відповідну точку. Кожна пара сусідніх вузлів готує незавершені підписи, прив’язані до свого точкового блокування; коли одержувач завершує останній підпис, різниця між адаптером і чинним підписом розкриває скаляр та запускає розрахунок назад маршрутом. [1]
Відправник може додати різні випадкові скаляри для окремих переходів, а вузли послідовно віднімають їхні точки. Два змовницькі маршрутизувальні вузли тоді не бачать однаковий payment hash, як у звичайному HTLC; кореляція за сумою, часом, строком дії чи топологією все одно можлива. [4]
BIP 340 задає для підписів Schnorr лінійне рівняння, завдяки якому адаптери підписів природніше компонувати, ніж з ECDSA. З агрегованим ключем успішна on-chain витрата може виглядати як звичайний підпис, але фактична економія місця залежить від конструкції каналу, multisignature протоколу та аварійного шляху. [2]
Безпека залежить не лише від точки й timelock. Реалізація має перевіряти адаптер, правильно зв’язувати підпис із повідомленням і ключем, захищати nonce, безпечно вилучати скаляр, зберігати шлях повернення та обробляти переривання контрагента; помилка може розкрити ключ або втратити кошти. [1]
Чинний базовий BOLT #2 досі описує update_add_htlc, update_fulfill_htlc та htlc_signature. Тому PTLC не є сумісною функцією звичайної Lightning Network лише через активність Taproot і BIP 340 у Bitcoin; потрібні погоджені повідомлення, стани каналу та сумісні реалізації. [3]
Обговорення розробників 2025 року вказує на відсутність стандартизованих зрілих інструментів для adaptor signatures з MuSig2 та окремих адаптерів Schnorr у поширених бібліотеках. PTLC є технічно опрацьованою пропозицією, але публічний стан інструментів і специфікацій не дозволяє заявляти про широке впровадження. [5]
PTLC може поліпшити декореляцію маршрутизованих платежів, proof of payment, атомарні багатомаршрутні платежі та деякі swaps. Сам по собі він не розв’язує доступність каналу, керування ліквідністю, втрату стану, зловмисне часування чи повну анонімність; перевагу слід оцінювати разом з onion routing і дизайном каналу. [4]
Для повної картини прочитайте також HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. На цю статтю також посилаються Trampoline Routing.
01Чи використовує звичайна Lightning Network сьогодні PTLC замість HTLC?+
Не як спільну сумісну основу. Чинні специфікації BOLT досі визначають повідомлення та підписи HTLC. Для PTLC потрібні додаткові криптографічні інструменти, повідомлення протоколу, переходи станів і згода реалізацій; сама активація Taproot не виконала цю міграцію.
02Чому PTLC приватніший за HTLC?+
Кілька переходів HTLC можуть нести однаковий payment hash і давати змовницьким вузлам пряме значення для кореляції. PTLC дозволяє кожному переходу змінити точкове блокування додаванням локальної точки. Сума, час, строк дії та позиція в мережі все одно можуть пов’язати платіж.