Hashed Timelock Contract는 해시 조건과 시간 잠금을 결합합니다. Lightning은 각 HTLC에 payment_hash, 금액, cltv_expiry를 사용합니다. 일치하는 payment_preimage로 경로를 거슬러 이행할 수 있고, timeout은 다른 정산 경로를 제공합니다. 안전성은 확약된 채널 상태, 서명, 적시 대응에도 달려 있습니다.
수신자는 SHA-256이 payment_hash와 일치하는 32바이트 payment_preimage를 제공합니다. BOLT 11은 인보이스의 p 필드에 해시를 넣습니다. 해시만으로 비밀이 드러나지는 않습니다. 같은 preimage가 이어지는 HTLC들의 조건을 연결합니다. s 필드의 payment_secret는 다른 값이며 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는 자체 매개변수를 갖습니다. BOLT 2에 따라 수신 HTLC 추가가 철회 불가능하게 확약되기 전에는 대응하는 발신 HTLC를 제안해서는 안 됩니다. [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, 시간 조건이 적용됩니다. 로컬 2단계 출력에는 to_self_delay의 CSV 지연이 있지만, 올바른 폐기 키를 가진 상대방은 그 지연 없이 페널티 분기를 사용할 수 있습니다. 정확한 Script는 채널 유형에 따라 달라집니다. [BOLT 3 — HTLC transaction scripts and trimming] [BIP 112 — CHECKSEQUENCEVERIFY]
적용되는 2단계 수수료를 뺀 금액이 dust_limit_satoshis보다 작으면 커밋먼트 트랜잭션은 HTLC 출력을 만들지 않습니다. 규칙은 협상된 유형에 따라 다릅니다. option_anchors와 zero_fee_commitments에는 해당 2단계 수수료가 없으며, 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를 비교하고 SHA-256으로 preimage를 검증하세요. fulfill/fail 메시지 하나만이 아니라 commitment_signed, revoke_and_ack 및 최종 상태도 추적하세요. 온체인 집행 시 실제 커밋먼트 트랜잭션을 디코딩하고 출력 존재 여부, 사용 분기, 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.