HTLC

يقدم المستلم payment_preimage بطول 32 بايت تكون نتيجة 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]

يشير cltv_expiry في Lightning إلى ارتفاع كتلة مطلق، وليس 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، فلا تنشئ معاملة الالتزام مخرج 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 واحدة فقط. عند التنفيذ على السلسلة، فك ترميز معاملة الالتزام الفعلية وتحقق من وجود المخرج والفرع المستخدم وHTLC-success/HTLC-timeout. افحص التوقيعات والشروط الزمنية والتأكيدات؛ فك الترميز وحده لا يثبت الصلاحية. [BOLT 2 — Channel state and HTLC handling] [BOLT 3 — HTLC transaction scripts and trimming]