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.