Hashed Timelock Contract हैश की शर्त को समय प्रतिबंध से जोड़ता है। Lightning हर HTLC के लिए payment_hash, राशि और cltv_expiry उपयोग करता है। मेल खाने वाली payment_preimage से मार्ग पर पीछे की ओर दायित्व पूरे किए जा सकते हैं; timeout वैकल्पिक निपटान देता है। सुरक्षा चैनलों की प्रतिबद्ध अवस्थाओं, हस्ताक्षरों और समय पर कार्रवाई पर भी निर्भर है।
प्राप्तकर्ता 32 बाइट की payment_preimage देता है जिसका SHA-256, payment_hash से मेल खाता है। 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 और समय शर्तें लागू होती हैं। दूसरे चरण के स्थानीय आउटपुट पर to_self_delay की CSV देरी होती है, जबकि सही revocation कुंजी दूसरे पक्ष को इस देरी के बिना दंड शाखा उपयोग करने देती है। सटीक 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 की तुलना करें; SHA-256 से preimage जाँचें। केवल एक fulfill/fail संदेश नहीं, commitment_signed, revoke_and_ack और अंतिम अवस्था भी देखें। ऑन-चेन प्रवर्तन में वास्तविक commitment लेनदेन डिकोड करें और आउटपुट की मौजूदगी, प्रयुक्त शाखा तथा HTLC-success/HTLC-timeout जाँचें। हस्ताक्षर, समय शर्तें और पुष्टि जाँचें; केवल decoding वैधता साबित नहीं करती। [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.