Hashed Timelock Contract поєднує хешову умову з часовим блокуванням. Lightning використовує payment_hash, суму та cltv_expiry для кожного HTLC. Відповідна payment_preimage дозволяє виконати зобов’язання у зворотному напрямку маршруту; timeout відкриває альтернативне врегулювання. Безпека також залежить від зафіксованих станів каналів, підписів і своєчасної реакції.
Одержувач надає 32-байтову payment_preimage, чий SHA-256 відповідає payment_hash. BOLT 11 розміщує хеш у полі p рахунка; сам хеш не розкриває секрет. Одна preimage пов’язує умови послідовних HTLC. payment_secret із поля s — інше значення, яке не замінює preimage. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry]
У Lightning cltv_expiry означає абсолютну висоту блока, а не Unix timestamp чи строк дії рахунка BOLT 11 у секундах. Після виконання часових умов може стати доступним витрачання через timeout. Дійсна preimage не припиняє працювати автоматично; конкуруючі витрачання одного виходу не можуть обидва підтвердитися в одному дійсному ланцюзі. Повернення не автоматичне. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry] [BIP 65 — CHECKLOCKTIMEVERIFY]
update_add_htlc пропонує додавання; update_fulfill_htlc або update_fail_htlc врегульовує виконання чи невдачу. Одне повідомлення не завершує зміну стану: commitment_signed і revoke_and_ack забезпечують підписи нового стану та відкликання старого з обох боків. Звичайному платежу не потрібен новий запис у блоці, але фінансування й закриття каналу використовують транзакції bitcoin. [BOLT 2 — Channel state and HTLC handling]
Основа повідомлення update_add_htlc містить channel_id, id, amount_msat, payment_hash, cltv_expiry та onion_routing_packet. amount_msat задається в millisatoshi. Вузол перевіряє обмеження каналу, доступну ліквідність і умови пересилання; вихідний HTLC має власні параметри. Відповідний HTLC не можна пропонувати, поки додавання вхідного не зафіксовано безвідклично за BOLT 2. [BOLT 2 — Channel state and HTLC handling]
Вузол розшифровує власний шар onion і перевіряє його цілісність. На звичайному незасліпленому маршруті він зіставляє amt_to_forward та outgoing_cltv_value із вхідною сумою, комісією та необхідною часовою різницею. Пакет не відкриває йому весь маршрут. Це не виключає кореляції трафіку чи іншого встановлення особи; onion routing не гарантує абсолютної анонімності. [BOLT 4 — Onion routing and payload validation]
Вхідний HTLC має спливати пізніше за відповідний вихідний HTLC. Різниця cltv_expiry_delta дає посереднику запас для отримання preimage, реакції на недоступність контрагента й підтвердження в блокчейні. Вона враховує затримки та реорганізації; кількість блоків не гарантує фіксованої кількості хвилин. Замалий запас загрожує коштам. [BOLT 2 — Channel state and HTLC handling]
BOLT 3 розрізняє виходи offered і received та шляхи HTLC-success або HTLC-timeout. Самого знання хешу недостатньо: діють відповідні підписи, preimage і часові умови. Локальний вихід другого етапу має CSV-затримку to_self_delay, а правильний ключ відкликання дозволяє контрагенту штрафну гілку без цієї затримки. Точний Script залежить від типу каналу. [BOLT 3 — HTLC transaction scripts and trimming] [BIP 112 — CHECKSEQUENCEVERIFY]
Якщо сума після відповідної комісії другого етапу нижча за dust_limit_satoshis, commitment-транзакція не створює вихід HTLC. Правила залежать від узгодженого типу: option_anchors і zero_fee_commitments не мають такої комісії другого етапу; zero_fee_commitments може спрямувати обрізану суму до shared_anchor. Відсутній вихід не можна окремо стягнути в блокчейні. Сукупність таких HTLC утворює dust exposure. [BOLT 3 — HTLC transaction scripts and trimming] [BOLT 2 — Channel state and HTLC handling]
Один секрет пов’язує умови вздовж маршруту, але прийняття пропозиції саме по собі не гарантує завершення платежу. Ліквідність, кількість доступних місць HTLC, комісії, строк і правила маршрутизації можуть його зупинити. Безпечне виконання чи відмова потребують правильного порядку змін і своєчасного врегулювання. Розкриття preimage не дорівнює підтвердженню транзакції bitcoin. [BOLT 2 — Channel state and HTLC handling] [BOLT 4 — Onion routing and payload validation]
Порівняй вхідні й вихідні amount_msat, payment_hash та cltv_expiry; перевір preimage через SHA-256. Відстежуй також commitment_signed, revoke_and_ack і кінцевий стан, а не лише одне повідомлення fulfill/fail. Для виконання в блокчейні декодуй справжню commitment-транзакцію, перевір наявність виходу, використану гілку та HTLC-success/HTLC-timeout. Перевір підписи, часові умови й підтвердження; саме декодування не доводить дійсність. [BOLT 2 — Channel state and HTLC handling] [BOLT 3 — HTLC transaction scripts and trimming]
Для повної картини прочитайте також Lightning Network, Payment Channel, Timelock, Криптографічний хеш, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. На цю статтю також посилаються Timelock, Payment Channel, Ліквідність Lightning, Lightning Routing.