165 / 691BOLT12

BOLT 12

عرض قابل للتكرار وفاتورة جديدة ودفعة مستقلة

يفصل BOLT 12 العرض المنشور عن طلب فاتورة محددة. رمز QR القابل لإعادة الاستخدام لا يحوّل المال بنفسه.

BOLT 12 بروتوكول تفاوض على دفع Lightning عبر offer ثم invoice_request ثم invoice. يمكن تكرار العرض، لكن لكل دفعة شروطها ونتيجتها التي يجب التحقق منها.

ينشر المستلم offer؛ يرسل الدافع invoice_request ويتلقى invoice جديدة. بعدها فقط يمكنه الدفع. قد يخدم العرض عدة أشخاص أو دفعات متكررة. جلب فاتورة مثلاً عبر fetchinvoice لا يسددها؛ ونشر QR ليس تفويضاً دائماً بالخصم. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]

يخزن BOLT 12 الحقول بصيغة TLV. بادئة العرض النصي lno وبادئة الطلب lnr؛ تشبه مجموعة المحارف Bech32 لكن دون مجموع تحقق نهائي. offer نفسه غير موقّع. تتحقق توقيعات Schnorr وفق BIP340 في الطلبات والفواتير من جذر Merkle للحقول، لا هوية التاجر. [BOLT 12 — Negotiation protocol]

تقارن المحفظة الحقول المنسوخة من invoice_request مع invoice والمبلغ والشبكة والتوقيع. يجب أن يطابق invoice_node_id قيمة offer_issuer_id أو blinded_node_id النهائي المناسب. لا يكفي توقيع صحيح غير ذي صلة. تسمح بنية Merkle بإثبات حقول انتقائياً، لا بتغيير الشروط الموقعة كيفما اتفق. [BOLT 12 — Negotiation protocol]

تكون invoice_amount لبيتكوين بوحدة msat؛ كل 1000 msat تساوي satoshi واحداً. يمكن أن تحدد offer_currency عملة أخرى وفق ISO 4217؛ يستخدم USD السنت مثلاً. تؤثر الكمية والتحويل عند إصدار الفاتورة في السعر. إذا حُدد invreq_amount وجب التطابق؛ وإلا يُتحقق من النطاق المصرح به. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]

يحمل offer_paths رسالة الطلب، ويحمل invoice_paths الدفع. يجب أن تتضمن invoice الحالية blinded paths وinvoice_blindedpay مطابقاً، حتى لمسار مباشر إلى المستلم. يقلل التعمية كشف بنية الشبكة دون ضمان مجهولية كاملة أو توفر أو سيولة. طلب الفاتورة لا يحتاج خادم دفع HTTPS عادياً. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]

يقيد offer_absolute_expiry استخدام العرض. ويقيد invoice_created_at مع invoice_relative_expiry الفاتورة المحددة؛ دون الحقل الثاني تُطبق 7200 ثانية. العرض المتكرر لا يمنح الفواتير صلاحية أبدية. تُرفض البتات الزوجية الإلزامية المجهولة، وتُتجاهل الفردية المجهولة. [BOLT 12 — Negotiation protocol]

عند رد المال يمكن لمن يريد إرساله نشر invoice_request دون offer. يرد مستلم المال بـinvoice خاصة به؛ ويجب أن يتحقق الدافع من المستلم المقصود، خارج البروتوكول عند الحاجة. هذه دفعة جديدة لا إلغاء للأصلية. مسح الطلب وحده لا يثبت استحقاقاً ولا موافقة على الدفع. [BOLT 12 — Negotiation protocol]

احتفظ بـinvoice وحالة الدفع وpreimage المطابق. يثبت preimage تسوية الفاتورة، لكنه وحده لا يحدد الشخص الذي دفع. عند فقدان الرد تحقق من الحالة قبل الدفع مجدداً. دعم العروض لا يعني دعم كل امتداد أو الدفعات الدورية الآلية؛ تحقق منفصلاً من الاستقبال والإرسال وصلاحيات التطبيق. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]

للحصول على صورة أوضح، اقرأ هذا المدخل مع BOLT 11, Lightning Network, Lightning Routing, خصوصية Bitcoin, Satoshi, LNURL. تشير إلى هذا المدخل أيضًا BOLT 11, LNURL.

DOC · 001BOLT 12 — Negotiation protocolمواصفة ↗DOC · 002BOLT 4 — Route blindingمواصفة ↗DOC · 003Core Lightning — Fetching an invoiceتوثيق ↗DOC · 004BOLT 12 — Project overviewمصدر أولي ↗
المصادر أولًا · ليست نصيحة استثمارية