LNURL

कल्पना करें कि आना पहले किसी लेखक को सहयोग देने वाला कोड स्कैन करती है, फिर वाउचर भुनाने का और आखिर में वेबसाइट पर लॉग इन करने का। फ़ोन चलाने का तरीका एक जैसा है, लेकिन हर बार वह अलग काम की अनुमति देती है। LNURL इन कामों में अंतर करता है: payRequest भुगतान के लिए, withdrawRequest निकासी के लिए और login लॉग इन के लिए है। LUD दस्तावेज़ हर प्रक्रिया समझाते हैं। ये ऐप के बीच सहयोग के वैकल्पिक नियम हैं, Bitcoin के नियमों में बदलाव नहीं। किसी वॉलेट में एक प्रक्रिया चलने का मतलब यह नहीं कि बाकी सभी भी चलेंगी। [1] [7]

payRequest में सेवा विवरण और स्वीकार्य रकम की सीमा लौटाती है। आना डोमेन, यानी सेवा का वेब पता जाँचती है, विवरण पढ़ती है और सहयोग की रकम चुनती है। शर्तें स्वीकार करने के बाद वॉलेट एक खास BOLT 11 Lightning इनवॉइस माँगता है और भुगतान से पहले उसकी रकम को चुनी गई रकम से मिलाता है। इसके पीछे callback पता, minSendable और maxSendable सीमाएँ तथा metadata विवरण काम करते हैं। रकम amount में भेजी जाती है और इनवॉइस pr में मिलता है। रकम msat में होती है, जो satoshi का हज़ारवाँ हिस्सा है: 1000 msat = 1 sat। दूसरे लोग भी वही सार्वजनिक QR इस्तेमाल कर सकते हैं, लेकिन उसे स्कैन करना भुगतान पूरा होने की पुष्टि नहीं है। [3]

withdrawRequest में दिशा उलटी होती है। आना सेवा को भुगतान नहीं करना चाहती, बल्कि वहाँ मौजूद अपना बैलेंस निकालना चाहती है। इसलिए उसका वॉलेट पैसे प्राप्त करने का इनवॉइस बनाता है, जिसका भुगतान सेवा करेगी। सेवा k1 पहचानकर्ता, callback पता और msat में minWithdrawable तथा maxWithdrawable सीमाएँ देती है। अनुमति के बाद वॉलेट अपना इनवॉइस pr में भेजता है। OK जवाब का मतलब है कि सेवा ने अनुरोध स्वीकार कर लिया, न कि आना को पैसे मिल गए। वॉलेट अभी वास्तविक भुगतान आने का इंतज़ार करता है। निकासी का कोड ऐसा वाउचर हो सकता है जिसे रखने वाला व्यक्ति भुना सके; इसे सामान्य भुगतान प्राप्त करने वाले संपर्क की तरह सार्वजनिक न करें। [4]

दूसरी वेबसाइट पर आना LNURL-auth चुनती है। वॉलेट डोमेन और tag login वाले अनुरोध का उद्देश्य दिखाता है। उसकी अनुमति से वॉलेट उस डोमेन की निजी कुंजी linkingPrivKey से एक बार काम आने वाले जाँच-अनुरोध k1 पर हस्ताक्षर करता है। वह सेवा को हस्ताक्षर और संबंधित सार्वजनिक कुंजी linkingKey भेजता है, जिससे हस्ताक्षर की जाँच की जा सकती है। निजी कुंजी नहीं भेजी जाती। इससे सेवा पहचान सकती है कि वही कुंजी रखने वाला व्यक्ति वापस आया है, लेकिन केवल इस जाँच से उसकी वास्तविक पहचान पता नहीं चलती। वॉलेट सेवा को seed, यानी वह शुरुआती गुप्त मान जिससे कुंजियाँ निकाली जाती हैं, या Seed Phrase, यानी रिकवरी के शब्द, नहीं भेजता। तकनीकी रूप से इसमें secp256k1 पर ECDSA हस्ताक्षर होता है। 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 जवाब से काम का प्रकार जानता है। JSON जानकारी को नाम और ढाँचा देता है, ताकि ऐप उसे पढ़ सके। इसलिए QR की तस्वीर अपने आप प्राप्तकर्ता की पहचान साबित नहीं करती। लिंक में क्या है और बाद में कौन-सा डोमेन, काम और शर्तें दिखाई जाती हैं, यही महत्त्वपूर्ण है। [2]

भुगतान की प्रक्रिया में metadata एक टेक्स्ट स्ट्रिंग होती है जिसके भीतर JSON ऐरे होता है। उसमें text/plain विवरण होना ज़रूरी है; बाकी प्रकार वैकल्पिक हैं। वॉलेट को विवरण के साथ डोमेन और रकम दिखानी चाहिए, ताकि व्यक्ति समझे कि वह किस बात की अनुमति दे रहा है। मूल LNURL जवाब के JSON भाग को पढ़ता है, केवल HTTP स्टेटस कोड को नहीं। इसलिए सर्वर का जवाब देना अनुरोध सफल होने का प्रमाण नहीं: जवाब के भीतर ERROR हो सकता है। इसी तरह pr में इनवॉइस मिलने का मतलब उसका भुगतान हो जाना नहीं है। ऐप को इन अलग जानकारियों को एक ही हरे निशान में नहीं समेटना चाहिए। [2] [3]