BOLT 11

تشتري آنا كتابًا إلكترونيًا. بدل بيانات حساب مصرفي، يعرض المتجر فاتورة Lightning تقرأ منها محفظتها معلومات الدفع. لا تحتاج آنا إلى فهم السلسلة الطويلة؛ بل تراجع المبلغ والغرض والرسوم قبل التأكيد. بعض الفواتير تترك المبلغ مفتوحًا، مثل المساهمات الطوعية، فيدخله الدافع. غياب المبلغ لا يعني دفع صفر. ولمن يريد التعمق: تشير lnbc إلى الشبكة الرئيسية، وlntb إلى testnet، وlntbs إلى signet، وlnbcrt إلى regtest، وهي بيئات اختبار. المبلغ المدوّن في الترميز مقوّم بوحدة BTC مع معامل اختياري m أو u أو n أو p، وليس مباشرة بوحدة satoshi. عند استخدام p يجب أن ينتهي العدد بالرقم 0 ليمثل عددًا صحيحًا من millisatoshi: 1000 msat = 1 sat. [1]

يربط الوصف الطلب التقني بهدف مفهوم، ككتاب آنا. تتضمن الفاتورة إما النص نفسه في الحقل d أو بصمته الرقمية في h. تُحسب البصمة بواسطة SHA256، وعلى المحفظة التحقق من أن الوصف المقدم بصورة منفصلة ينتج البصمة نفسها. تسمى قيمة التحقق القصيرة هذه، المحسوبة من النص، هاشًا. لا يمكن قراءة الطلب من البصمة وحدها. يربط التوقيع الصحيح الوصف بمفتاح المستلم، لكنه لا يعد بأن التاجر سيسلّم الكتاب. وعلى مطوري التطبيقات أيضًا أن يتعاملوا مع الوصف بوصفه نصًا خارجيًا: يُعرض بأمان كبيانات ولا يُنفذ أبدًا كشيفرة. [1]

تترك آنا الطلب مفتوحًا وتعود لاحقًا. إذا أخبرتها المحفظة بأن الفاتورة انتهت، فعليها طلب فاتورة جديدة. يُحسب انتهاء الصلاحية من وقت الإنشاء timestamp والمدة x. إذا غاب x فالقيمة الافتراضية 3600 ثانية، أي ساعة. انتهاء الصلاحية لا يعكس دفعة اكتملت. أما الحقل c، واسمه التقني min_final_cltv_expiry_delta، فيحدد شيئًا آخر: هامشًا زمنيًا لآخر دفعة مشروطة HTLC في المسار. يشترط HTLC تقديم السر الصحيح في الوقت المحدد لإتمام التسوية. يُقاس هذا الهامش بالكتل، لا بثواني صلاحية الفاتورة؛ ومن دون c يستخدم الدافع 18 كتلة على الأقل. لا ينبغي الخلط بين هذين الزمنين. [1]

تمر دفعة Lightning عبر قنوات دفع. داخل القناة يحدّث طرفان توزيع الأموال بينهما من دون تسجيل كل دفعة عادية على سلسلة كتل Bitcoin الرئيسية. وتحتاج إلى مسار قابل للاستخدام وأموال كافية على الجوانب المناسبة من القنوات، أي سيولة. قد يتضمن الحقل r ما يسمى routing hints، وهي إرشادات للجزء الأخير من المسار. تساعد على الوصول إلى المستلم، لكنها ليست تقريرًا مباشرًا عن السعة المتاحة. وقد تكشف أيضًا مفاتيح عامة للعقد ومعرّفات قنوات ومعايير رسوم؛ لذلك لا تعتبر الفاتورة الكاملة وثيقة خاصة. يمكن للحقل الاختياري f تقديم عنوان Bitcoin عادي كبديل. الدفع إليه يستخدم السلسلة الرئيسية برسومه وتأكيداته الخاصة. ليس مجرد زر آخر لطريقة الإرسال نفسها. [1] [2] [5]

مسح QR أو استلام فاتورة لا يساوي الحصول على إيصال. بعد الإرسال راجع النتيجة في المحفظة؛ فالمعلّق يختلف عن المكتمل. ومن أدلة التسوية أيضًا preimage الصحيح، وهو قيمة سرية يجب أن يطابق هاشها هاش الدفع الموجود في الفاتورة. يمكن الاحتفاظ بكليهما كدليل على الدفع، لا كضمان لتسليم السلعة. إذا انقطع اتصال التطبيق أو ضاعت الاستجابة، فتحقق أولًا من حالة الدفعة الأصلية. طلب فاتورة جديدة فورًا أو الدفع إلى العنوان البديل قد يعني دفعًا آخر. بعض المحافظ تتعرف على إعادة المحاولة، لكن الصيغة نفسها لا تقدم حماية شاملة عبر التطبيقات وطرق الدفع المختلفة. [2] [4]

تستخدم السلسلة الطويلة ترميز Bech32. يساعد المجموع الاختباري على كشف أخطاء النسخ؛ لكنه ليس تشفيرًا ولا يخفي المحتوى. وللتوقيع الرقمي ECDSA على secp256k1 وظيفة أخرى: التحقق من ارتباط بيانات الدفع بمفتاح المستلم ومن عدم تغييرها لاحقًا. لا يثبت الهوية القانونية أو نزاهة الشخص خلف المفتاح. وبخلاف عناوين Bitcoin بترميز Bech32، يمكن أن يتجاوز BOLT 11 عدد 90 محرفًا. تناسب الأحرف الكبيرة رموز QR، لكن السلسلة الصحيحة لا تخلط الكبيرة والصغيرة. يمسح الشخص الرمز أو ينسخه عادة، بينما تنفذ المحفظة هذه الفحوص. [1]

payment hash هو البصمة الرقمية لقيمة سرية تسمى payment preimage، تُحسب بواسطة SHA256 وتوضع في الحقل p. عند نجاح التسوية يعرف الدافع preimage ويمكنه التحقق من تطابق البصمة. أما الحقل s فيحمل payment_secret. يقرأ الدافع هذا المعطى من الفاتورة أصلًا وينقله إلى المستلم في الجزء الأخير من الدفع الموجّه؛ ويساعد على حماية المستلم من محاولات الاستكشاف التي تجريها العقد الوسيطة. Secret ليس preimage ولا seed المحفظة. قراءته من QR لا تثبت الدفع ولا تتيح استعادة المحفظة. يتطلب BOLT 11 الحالي كلا الحقلين p وs. وراء الأسماء المتشابهة وظائف مختلفة: تحديد الدفعة، وتقديم قيمة لازمة، وإثبات التسوية. [1] [2]

تحتاج المحافظ أيضًا إلى معرفة ما إذا كانت تدعم الدفع المطلوب. يحمل الحقل 9 أعلام الميزات. البت الزوجي غير المعروف يعني ميزة إلزامية تستوجب رفض الدفع؛ أما الفردي غير المعروف فاختياري ويمكن تجاهله. ويجب كذلك استيفاء الاعتماديات المعروفة بين الميزات. مثلًا يقسم Basic MPP دفعة واحدة إلى أجزاء تُجمع عند المستلم، ولا يجوز استخدامه إلا إذا عرضت الفاتورة basic_mpp. لا ينشئ التقسيم فواتير مستقلة ولا سببًا لدفع كل جزء من جديد. والخلاصة العملية للمبتدئ: لا تتجاوز رسالة عدم دعم ميزة بتعديل الفاتورة يدويًا؛ عالج توافق المحافظ أولًا. [1] [3]