166 / 736LNURL

LNURL

رمز QR واحد، ومهام مختلفة للمحفظة

لا يطلب منك رمز QR الدفع دائمًا. مع LNURL، يمكن للمحفظة أيضًا استلام المال أو تسجيل دخولك إلى موقع. المهم هو أن تفهم الإجراء الذي توافق عليه بعد مسح الرمز.

LNURL عائلة من الإجراءات تتبادل من خلالها محفظة Lightning وخدمة ويب المعلومات اللازمة لمهمة معينة. يُستخدم Lightning للدفع السريع بالبيتكوين؛ والفاتورة فيه طلب دفع يحتوي على البيانات التي تحتاجها المحفظة لإتمامه. تتعرف المحفظة من الرابط على ما إذا كان المطلوب إعداد دفعة، أو استلام أموال مسحوبة من خدمة، أو تأكيد تسجيل دخول. الرابط بحد ذاته ليس فاتورة ولا دليلًا على وصول المال.

تخيّل آنا تمسح رمزًا لدعم كاتب، ثم رمزًا لاسترداد قسيمة، وأخيرًا رمزًا للدخول إلى موقع. تستخدم هاتفها بالطريقة نفسها، لكنها توافق على أمر مختلف كل مرة. يميّز LNURL هذه المهام: يشير payRequest إلى الدفع، وwithdrawRequest إلى السحب، وlogin إلى تسجيل الدخول. وتصف وثائق LUD كل إجراء. إنها اتفاقات اختيارية بين التطبيقات، وليست تغييرًا لقواعد Bitcoin. دعم المحفظة لإجراء معين لا يعني أنها تدعم جميع الإجراءات الأخرى. [1] [7]

في payRequest، تعيد الخدمة وصفًا ونطاقًا للمبالغ المسموحة. تتحقق آنا من اسم النطاق الذي يعرّف الخدمة في عنوان الويب، وتقرأ الوصف وتختار مساهمتها. وبعد موافقتها على الشروط، تطلب المحفظة فاتورة Lightning محددة بصيغة BOLT 11 وتطابق مبلغها مع اختيارها قبل الدفع. تستخدم عنوان callback وحدّي minSendable وmaxSendable ووصف metadata؛ وترسل المبلغ في amount وتتلقى الفاتورة في pr. تُقاس المبالغ بوحدة msat، أي أجزاء من ألف من satoshi: 1000 msat = 1 sat. يستطيع آخرون استخدام رمز QR العام نفسه، لكن مسحه لا يؤكد إتمام الدفع. [3]

في withdrawRequest ينعكس الاتجاه. تريد آنا سحب رصيد من الخدمة، لا الدفع لها. لذلك تنشئ محفظتها فاتورة لاستلام المال، وعلى الخدمة سدادها. توفر الخدمة المعرّف k1 وعنوان callback وحدّي minWithdrawable وmaxWithdrawable بوحدة msat؛ وبعد الموافقة ترسل المحفظة فاتورتها في pr. تعني الإجابة OK أن الخدمة قبلت الطلب، لا أن آنا استلمت المال بالفعل. وتظل المحفظة تنتظر الدفعة الواردة. قد يعمل رمز السحب كقسيمة يستطيع حاملها استرداد قيمتها؛ لذلك لا تنشره كما تنشر وسيلة عادية لاستقبال المدفوعات. [4]

تختار آنا LNURL-auth في موقع آخر. تعرض المحفظة اسم النطاق والغرض من الطلب الذي يحمل tag login. وبموافقتها، توقّع طلب تحقق يُستخدم مرة واحدة اسمه k1 بالمفتاح الخاص المخصص لهذا النطاق، linkingPrivKey. وترسل إلى الخدمة التوقيع والمفتاح العام المقابل linkingKey، الذي يتيح التحقق من التوقيع. ولا ترسل المفتاح الخاص. تستطيع الخدمة بذلك تمييز صاحب المفتاح عند عودته، لكن هذا التحقق وحده لا يكشف هويته الحقيقية. لا ترسل المحفظة إلى الخدمة seed، وهي القيمة السرية الأولية التي تُشتق منها المفاتيح، ولا Seed Phrase، أي كلمات الاستعادة. تقنيًا، تستخدم توقيع ECDSA على المنحنى secp256k1. وقد يعني حقل action إنشاء حساب أو تسجيل الدخول أو ربط حساب أو منح إذن آخر، لذا من المهم قراءة التأكيد كاملًا. توقيع هذا التحدي ليس بحد ذاته دفعة Bitcoin. [5]

الطلب ورد الخدمة وانتقال المال فعلًا مراحل مختلفة. إذا انقطع اتصال آنا، فإنها تتحقق أولًا من الدفعة الأصلية في محفظتها. وقد تؤدي محاولة جديدة بفاتورة جديدة إلى دفعة إضافية. يضيف الإجراء الاختياري LUD-21 عنوان verify لفحص فاتورة محددة: settled true يعني أن الخدمة تبلغ عن تسويتها، وsettled false أنها لم تُسوَّ بعد. لا تكفي OK وحدها. قد يتضمن الرد preimage، وهي القيمة السرية الأصلية المرتبطة بالدفع. تحسب المحفظة منها هاشًا، أي قيمة للتحقق، وتقارنه بهاش الدفع في الفاتورة الصحيحة. فلا يكفي تلقي أي قيمة سرية؛ بل يجب أن تطابق هذه الدفعة تحديدًا. لكن فحص النتيجة لا يضمن توفر الخدمة أو السيولة الواردة، أي القدرة على توجيه المال إلى المحفظة المستقبِلة. [6] [3] [4]

يحمي HTTPS نقل البيانات بين المحفظة والخدمة، لكنه لا يخفيها عن الخدمة نفسها. فقد تراقب الطلبات وتوقيتها وتكرار الاستخدام. ويُعتدّ أيضًا باسم النطاق كاملًا عند تسجيل الدخول: تغيير النطاق الفرعي قد ينتج linkingKey مختلفًا، فيتعامل الموقع مع الشخص كمستخدم آخر. كما أن الانتقال إلى محفظة أخرى لا يضمن استعادة الدخول نفسه، لأن التطبيقات تشتق المفاتيح بطرق مختلفة. قبل تغيير مهم، تحقق من كيفية استعادة الوصول إلى ذلك الحساب تحديدًا. لا يحدد LNURL من يحتفظ بمفاتيح bitcoin؛ فهذا يعتمد على المحفظة والخدمة. [2] [5]

يمثل LUD-01 الأساسي عنوان HTTPS أو onion URL بصيغة Bech32. هذا ترميز، وليس تشفيرًا للعنوان ولا فاتورة BOLT 11. تقرأ المحفظة tag من الرابط مباشرة، أو ترسل طلب ويب GET لجلب البيانات وتتعرف على العملية من رد JSON. يمنح هذا التنسيق البيانات أسماء وبنية يمكن للتطبيق قراءتها. لذلك لا تثبت صورة QR وحدها هوية المستلم. ما يهم هو محتوى الرابط ثم النطاق والإجراء والشروط المعروضة. [2]

في إجراء الدفع، تكون metadata سلسلة نصية تحتوي على مصفوفة JSON. ويجب أن تتضمن وصفًا من نوع text/plain؛ أما الأنواع الأخرى فاختيارية. ينبغي للمحفظة عرض الوصف مع النطاق والمبلغ ليعرف المستخدم ما يوافق عليه. يفسر LNURL الأساسي محتوى الرد بصيغة JSON، لا رمز حالة HTTP وحده. لذلك لا تعني استجابة الخادم نجاح الطلب بالضرورة: قد يتضمن الرد ERROR. وبالمثل، الفاتورة التي وصلت في pr لم تُدفع بعد. لا ينبغي للتطبيق اختزال هذه المعلومات المختلفة في علامة خضراء واحدة. [2] [3]

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

DOC · 001LNURL — LUD indexمواصفة DOC · 002LNURL — LUD-01 encodingمواصفة DOC · 003LNURL — LUD-06 payRequestمواصفة DOC · 004LNURL — LUD-03 withdrawRequestمواصفة DOC · 005LNURL — LUD-04 authenticationمواصفة DOC · 006LNURL — LUD-21 verificationمواصفة DOC · 007Lightning Labs — LNURL glossaryتوثيق
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية